Problems with info (emacs version)

Problems with info (emacs version)

[Luc Teirlinck]

The concrete problem in info I described earlier concerning the `g'
and `m' commands and invisible text have been solved by a recent
change in the info files themselves by Stefan.

Other, some substantially more severe, problems related to the
existence of "secret text" (because for the user not extremely
familiar with both the invisibility and display properties, that is
exactly what it is) in info, remain.

1.  Easiest one to fix:

    (info)Help-M

    which is used in the tutorial, *only* describes menus as they
    appear in the standalone info, not as they appear in the emacs
    version and the two are very different.  A poor newbie, trying to
    use the tutorial to learn the Emacs version of info, will be
    completely confused, not because he is dumb, but because the
    information does not apply.  This one, is, of course, relatively
    easy to fix.

2.  The problem I described earlier with putting point on
    "* echo" (or similar) and doing M-x man.  No colon in the text,
    no colon in the minibuffer prompt, no "invisible text" (just text
    with the display property), but:

    Error in process sentinel: Can't find the echo: manpage

3.  Invisible text suddenly becomes visible when yanked inside an
    Emacs buffer (by default).  Text with the display property does
    not when yanked in an Emacs buffer, but does when yanked into
    other applications.  Try to make sense of that if you do not know
    about the invisibility property, yank-ignored-properties or the
    display property.  (I would guess that most newbies or casual
    users do not know about any of these, let alone about all of them
    and their subtleties.)  Some text appears completely out of
    nowhere when yanking into an Emacs buffer and then suddenly even
    more text appears when yanking it elsewhere.  What is going on?

4.  Both invisible text and text hidden by the display property
    becomes visible when copied to a file.  The casual user has no
    idea what he is copying to file.

5.  Last and definitely worst.  The user copies part of the info
    buffer into an emacs mail buffer for somebody elses information.
    What the receiver receives is not what the sender believes he
    sent.  Granted, the hidden text does not exactly consist of
    obscenities or such (although I did not yet try to read these node
    names backward to get all the Satanic messages), but this is still
    really bad.

There are plenty of other potential problems, but the above five are
representative.

I have no problems with the way outline mode and C-x $ treat invisible
text, the user chooses to make it invisible.  But the presence of
invisible text of any kind should always be made completely clear to
the user.  Otherwise, there is no limit to the problems that can
arise.

Possible solutions:

1.  The most radical solution would be to make all of that text
    visible.  End of all five problems, as well as of all related
    ones.  Also makes the Emacs info look like the standalone one.
    Less to get used to for people who want to use both.

2.  Actually erase the text (in the buffer) instead of making it
    invisible or giving it the display property.

    This might give problems for the `e' command, but editing using
    the `e' command does not seem like a very desirable thing to do
    anyway.

3.  The least radical and probably most acceptable of the three:
    provide a convenient command to toggle between the "emacs view"
    and the "standalone view" by making not only the invisible text
    visible, but also removing the display property.  But, in this
    case, one should make *really* sure that the user knows about the
    invisible text and about the command to make it visible.

Sincerely,

Luc.

Re: Problems with info (emacs version)

[Eli Zaretskii]

> Date: Sun, 1 Jun 2003 22:33:22 -0500 (CDT)
> From: Luc Teirlinck <teirllm@dms.auburn.edu>
> 
> 5.  Last and definitely worst.  The user copies part of the info
>     buffer into an emacs mail buffer for somebody elses information.
>     What the receiver receives is not what the sender believes he
>     sent.  Granted, the hidden text does not exactly consist of
>     obscenities or such (although I did not yet try to read these node
>     names backward to get all the Satanic messages), but this is still
>     really bad.

I think `yank' should by default simply strip all text properties.  As
it currently works, it tends to surprise users, even if the properties
have some visible effect, and in my experience, most uses of `yank'
don't need to preserve the properties anyway.  I find myself doing a
"M-g M-g" quite a lot in these cases.

We could then have some optional feature to give the current behavior,
like a variable or a special value of the numeric argument to C-y.

Re: Problems with info (emacs version)

[Kenichi Handa]

In article <7443-Mon02Jun2003072943+0300-eliz@elta.co.il>, "Eli Zaretskii" <eliz@elta.co.il> writes:
> I think `yank' should by default simply strip all text
> properties.  As it currently works, it tends to surprise
> users, even if the properties have some visible effect,

At least composition property should not be stripped until I
install on-the-fly-composition feature in HEAD
(emacs-unicode already has that).  I think display property
should be retained too.

---
Ken'ichi HANDA
handa@m17n.org

Re: Problems with info (emacs version)

[Stefan Monnier]

> 3.  Invisible text suddenly becomes visible when yanked inside an
>     Emacs buffer (by default).  Text with the display property does
>     not when yanked in an Emacs buffer, but does when yanked into
>     other applications.  Try to make sense of that if you do not know
>     about the invisibility property, yank-ignored-properties or the
>     display property.  (I would guess that most newbies or casual
>     users do not know about any of these, let alone about all of them
>     and their subtleties.)  Some text appears completely out of
>     nowhere when yanking into an Emacs buffer and then suddenly even
>     more text appears when yanking it elsewhere.  What is going on?

I think we should solve the above as follows:
Instead of marking lines as:

   * CVS:(cvs).			The CVS thingy.
        ^^^^^^^^^^^^^^^^^^^^^^^^
        (display "             ")

we should mark them as follows:

   * CVS:(cvs).			The CVS thingy.
        ^^^^^^^ ^^^^^^^^^^^^^^^^
      invisible (display (space :align-to 24))

the idea being that `display' is only used to turn a set of spaces
into some other representation of "some number of space".  and the
text that's really made invisible uses the `invisible' property,
so the rest of Emacs knows better how to handle it.


	Stefan

Re: Problems with info (emacs version)

[Luc Teirlinck]

Stefan Monnier wrote:

   I think we should solve the above as follows:
   Instead of marking lines as:

      * CVS:(cvs).			The CVS thingy.
	   ^^^^^^^^^^^^^^^^^^^^^^^^
	   (display "             ")

   we should mark them as follows:

      * CVS:(cvs).			The CVS thingy.
	   ^^^^^^^ ^^^^^^^^^^^^^^^^
	 invisible (display (space :align-to 24))

   the idea being that `display' is only used to turn a set of spaces
   into some other representation of "some number of space".  and the
   text that's really made invisible uses the `invisible' property,
   so the rest of Emacs knows better how to handle it.

That would be a big improvement.  I still believe that it is necessary
to make sure that the user knows that there is invisible text in the
buffer (otherwise there are just countless ways the user could get
confused, I just pointed out some examples) and to provide a
convenient command to toggle invisible text, which could, for instance
behave minor-mode style.  After the change you suggest, providing such
a command should be trivial, it would just have to toggle
buffer-invisibility-spec between t and nil.  Of course, one should
also make sure that the user knows about the command.

Sincerely,

Luc.

Re: Problems with info (emacs version)

[Richard Stallman]

    1.  Easiest one to fix:

	(info)Help-M

	which is used in the tutorial, *only* describes menus as they
	appear in the standalone info, not as they appear in the emacs
	version and the two are very different.

Would you please tell me the specific differences?  I scanned through
that none and did not notice anything incorrect.

    5.  Last and definitely worst.  The user copies part of the info
	buffer into an emacs mail buffer for somebody elses information.
	What the receiver receives is not what the sender believes he
	sent.  Granted, the hidden text does not exactly consist of
	obscenities or such (although I did not yet try to read these node
	names backward to get all the Satanic messages), but this is still
	really bad.

I am surprised you think this is such a serious issue.
Could you provide a test case where it causes a real problem?

Re: Problems with info (emacs version)

[Richard Stallman]

    I think `yank' should by default simply strip all text properties.

Yank does discard most text properties.  It discards `invisible'
properties, for instance.  It does not discard `display' properties,
and probably it should not discard them, so that you can kill and yank
an image.

Re: Problems with info (emacs version)

[Luc Teirlinck]

Richard Stallman wrote:

       I think `yank' should by default simply strip all text properties.

   Yank does discard most text properties.  It discards `invisible'
   properties, for instance.  It does not discard `display' properties,
   and probably it should not discard them, so that you can kill and yank
   an image.

People who agree with Eli can set `yank-excluded-properties' to t, but
the current documentation string makes this insufficiently clear.  I
propose to change the documentation string of yank-excluded properties
from:

  "*Text properties to discard when yanking."

To:

  "*Text properties to discard when yanking.
The value should be a list of text properties to discard or t,
which means to discard all text properties."

Now that I have write access, I could commit that change, if you agree
with it.

Sincerely,

Luc.

Re: Problems with info (emacs version)

[Luc Teirlinck]

Richard Stallman wrote:

       1.  Easiest one to fix:

	   (info)Help-M

	   which is used in the tutorial, *only* describes menus as they
	   appear in the standalone info, not as they appear in the emacs
	   version and the two are very different.

   Would you please tell me the specific differences?  I scanned through
   that none and did not notice anything incorrect.

Yes. From (info)Help-M:

       * Foo:  Node about FOO.      This tells about FOO.

     The subtopic name is Foo, and the node describing it is `Node about
  FOO'.  The rest of the line is just for the reader's Information.  [[
  But this line is not a real menu item, simply because there is no line
  above it which starts with `* Menu:'.]]

     When you use a menu to go to another node (in a way that will be
  described soon), what you specify is the subtopic name, the first
  thing
  in the menu line.  Info uses it to find the menu line, extracts the
  node name from it, and goes to that node.  The reason that there is
  both a subtopic name and a node name is that the node name must be
  meaningful to the computer and may therefore have to be ugly looking.
  The subtopic name can be chosen just to be convenient for the user to
  specify.  Often the node name is convenient for the user to specify
  and
  so both it and the subtopic name are the same.  There is an
  abbreviation for this:

       * Foo::   This tells about FOO.

  This means that the subtopic name and node name are the same; they are
  both `Foo'.

My own remarks:

Note that this goes into quite some length explaining why the user
sees both a 

"*Foo:" and a "Node about Foo" and what the difference is,

but the user using Emacs, sees only:

"*Foo".  Nowhere is it told that ":   Node about FOO" is normally
invisible in Emacs.  The user looks for it, can not find it and does
not know what is going on.

       * Foo::   This tells about FOO.

  This means that the subtopic name and node name are the same; they
  are
  both `Foo'.

Again, only:

* Foo is visible in Emacs, not the "::" The Emacs info user has no
  idea what all of this stuff about special meaning of "::" is about.

Of course, the entire discussion *is* correct if you know about the
invisible text.  One would not have to make a lot of changes in the
documentation if one would provide the user with convenient commands
in Info to toggle invisibility, say `v'. All one would have to do
would be to tell the user that in Emacs you first have to type `v' to
see the text being talked about.  I could easily implement such a
visibility toggling feature myself, if you would agree with it.

Sincerely,

Luc.

Re: Problems with info (emacs version)

[Luc Teirlinck]

Richard Stallman wrote:

       5.  Last and definitely worst.  The user copies part of the info
	   buffer into an emacs mail buffer for somebody elses information.
	   What the receiver receives is not what the sender believes he
	   sent.  Granted, the hidden text does not exactly consist of
	   obscenities or such (although I did not yet try to read these node
	   names backward to get all the Satanic messages), but this is still
	   really bad.

   I am surprised you think this is such a serious issue.
   Could you provide a test case where it causes a real problem?

It all depends on what you consider a "real" problem.  If I send
somebody mail, I like to now exactly what I sent.  Does that seem
unreasonable?

Assume that I am a newbie knowing nothing about the subtleties of the
display property.

I am asking somebody for help about how to use info and mail him a
copy of part of my info file:

* du                 Report on disk usage.
* echo               Print a line of text.

Without telling me, Emacs sends the following:

* du: (fileutils)du invocation.                 Report on disk usage.
* echo: (sh-utils)echo invocation.              Print a line of text.

I am careful, because I like to have exact records of everything I
mailed, so I FCC to my mail archive file.  Emacs copies:

* du                 Report on disk usage.
* echo               Print a line of text.

to my mail archive file.

The other person sends me all kinds of explanations about how I can
use the "(fileutils)du invocation" with the g command or whatever.

I say: but there is no "(fileutils)du invocation" in my buffer.  He
says: yes, it is in the stuff you mailed me.  I say, I never sent you
that, I have an archive file and I double checked what I sent you...

Do you consider the above a "real" problem?  I do.

Sincerely,

Luc.

Re: Problems with info (emacs version)

[Simon Josefsson]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Richard Stallman wrote:
>
>        5.  Last and definitely worst.  The user copies part of the info
> 	   buffer into an emacs mail buffer for somebody elses information.
> 	   What the receiver receives is not what the sender believes he
> 	   sent.  Granted, the hidden text does not exactly consist of
> 	   obscenities or such (although I did not yet try to read these node
> 	   names backward to get all the Satanic messages), but this is still
> 	   really bad.
>
>    I am surprised you think this is such a serious issue.
>    Could you provide a test case where it causes a real problem?
>
> It all depends on what you consider a "real" problem.  If I send
> somebody mail, I like to now exactly what I sent.  Does that seem
> unreasonable?
>
> Assume that I am a newbie knowing nothing about the subtleties of the
> display property.
>
> I am asking somebody for help about how to use info and mail him a
> copy of part of my info file:
>
> * du                 Report on disk usage.
> * echo               Print a line of text.
>
> Without telling me, Emacs sends the following:
>
> * du: (fileutils)du invocation.                 Report on disk usage.
> * echo: (sh-utils)echo invocation.              Print a line of text.

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.

> I am careful, because I like to have exact records of everything I
> mailed, so I FCC to my mail archive file.  Emacs copies:
>
> * du                 Report on disk usage.
> * echo               Print a line of text.
>
> to my mail archive file.

Uhm, really?  I don't believe this is what happens, hidden text are
saved just like non-hidden text.

> Do you consider the above a "real" problem?  I do.

Me too, but I don't think the problem is with info.

Re: Problems with info (emacs version)

[Miles Bader]

Simon Josefsson <jas@extundo.com> writes:
> 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.

That's a solution, but not a very good one in my experience.
I think final message sending is the wrong time to do this -- whenever I
get that message I'm a bit surprised and unsure what to do, as it's not
always clear _where_ the invisible text was, and having to go back and
re-edit a message that I thought was ready to send is very annoying.

What's wrong with just adding `invisible' to the default list of
properties stripped by yanking?

-Miles
-- 
Would you like fries with that?

Re: Problems with info (emacs version)

[Simon Josefsson]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Simon Josefsson <jas@extundo.com> writes:
>> 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.
>
> That's a solution, but not a very good one in my experience.
> I think final message sending is the wrong time to do this -- whenever I
> get that message I'm a bit surprised and unsure what to do, as it's not
> always clear _where_ the invisible text was, and having to go back and
> re-edit a message that I thought was ready to send is very annoying.

I agree!  A similar topic was just discussed on the ding mailing list.
A better solution may be to somehow visually highlight the hidden
text.  That may sound like a contradiction, but of course, it should
only happen that way in the mail buffer, so makes some sense.

> What's wrong with just adding `invisible' to the default list of
> properties stripped by yanking?

Could work.  But if, say, message uses the invisible property
internally to keep some hidden data around in the buffer, cut'n'paste
within the message buffer can generate unexpected result.

Re: Problems with info (emacs version)

[Miles Bader]

Simon Josefsson <jas@extundo.com> writes:
> > What's wrong with just adding `invisible' to the default list of
> > properties stripped by yanking?
> 
> Could work.  But if, say, message uses the invisible property
> internally to keep some hidden data around in the buffer, cut'n'paste
> within the message buffer can generate unexpected result.

Well, does it?  Unless there are real concrete cases where stripping
invisible would be bad, it seems silly to go around making kludgey
solutions when such an obvious (and easy) one is staring right at you...

-Miles
-- 
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over.  --Ian Wolff

Re: Problems with info (emacs version)

[Luc Teirlinck]

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.

Re: Problems with info (emacs version)

[Luc Teirlinck]

Simon Josefsson wrote:

   Uhm, really?  I don't believe this is what happens, hidden text are
   saved just like non-hidden text.

Indeed.

>From my previous message:

   I am careful, because I like to have exact records of everything I
   mailed, so I FCC to my mail archive file.  Emacs copies:

   * du                 Report on disk usage.
   * echo               Print a line of text.

   to my mail archive file.

This part is not as bad as I originally thought.  Emacs actually
copied this text to a mail archive buffer (not file).  When I saved my
archive file, killed the buffer and revisited the file, the hidden
text appeared.  Of course, text properties do not get saved to file, I
should have thought of that.

Sincerely,

Luc.

Re: Problems with info (emacs version)

[David Kastrup]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> 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.

And I think it shouldn't.  On my eternal todo-list is a way of sending
out formulas as attachments in a buffer.  The formulas should display
as formulas and would be generated with specific commands that would
probably have an MML command covered by display property of the
formula.

This should get sent without problems.  On the other hand, _pasting_
stuff with the display property from a different buffer where the
corresponding text for generating the picture might be something
completely different, is not going to be a good idea.

Underlying a display property may be something that only bears
relation to a particular buffer.

Ok, in this case I get saved by a whisker since I actually use
overlays (which don't exist in XEmacs), and overlays are buffer
properties, not text properties.

But the point was: the display property might serve a purpose in a
mail buffer.  Maybe for a specific purpose, one would again use an
overlay (and then be sure that, being generated buffer-specifically,
the covered text is fit for sending in a mail buffer).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Problems with info (emacs version)

[Stefan Monnier]

> This should get sent without problems.  On the other hand, _pasting_
> stuff with the display property from a different buffer where the
> corresponding text for generating the picture might be something
> completely different, is not going to be a good idea.

You could use the new `yank-function' stuff to translate the
LaTeX representation into a representation suitable for the
buffer into which it's pasted.


	Stefan

Re: Problems with info (emacs version)

[Luc Teirlinck]

I believe this discussion has gotten too much into the nitty-gritty
details of the problems involved and not focused enough on the
underlying common cause for all these problems and the general
solution, which I believe is not that difficult.

I believe that there are appropriate and inappropriate uses for the
invisibility and display properties.  If you use them in an
inappropriate way all the reported problems, as well as countless
others, appear.  If you use them appropriately they do not, or at
least only in a way less severe fashion.

The following represents my personal opinion:

Invisibility property:

Appropriate:

In a long text, sometimes you want to focus on the details and
sometimes you want to get an overview.  Give the details the
invisibility property (or various invisibility properties
corresponding to various level of detail) and provide user commands to
toggle invisibility.

Inappropriate:

Using the invisibility properties for internal Emacs purposes.  As the
various problems I reported show, there is nothing "internal" about
the invisibility property.

Conclusion:

Always use the invisibility property as a user feature, never as an
internal feature.  Always make sure that the user knows about
invisible text.  Always provide convenient commands to toggle
invisibility.

Display property:

Appropriate:

>From the Elisp manual:

`display' This property activates various features that change the way
     text is displayed.  For example, it can make text appear taller
     or shorter, higher or lower, wider or narrow, or replaced with an
     image.

Inappropriate:

As a way to make text impossible to see, without making it invisible,
by displaying it as whitespace (as info does extensively), or, more
generally, as a way to display regular text as some other regular text
with unrelated content, as an alternative for such lowly tools,
typically used by the unsophisticated masses, as deletion and
insertion.

The solution I propose for info is not that difficult:

1.  Replace the pseudo-invisible text with text having the
    invisibility property (see Stefan's proposal earlier in this
    thread for more details).

2.  Provide a command in info, say `v' that toggles visibility.
    make sure the user knows about it.

Sincerely,

Luc.

Re: Problems with info (emacs version)

[Luc Teirlinck]

David  Kastrup wrote:

   And I think it shouldn't.

Something I forgot to make clear: I am not arguing that message mode
should check for the display property, I am claiming that the info
style use of the display property is inappropriate, as I explained in
my previous message.

Sincerely,

Luc.

Re: Problems with info (emacs version)

[Robert J. Chassell]

Luc Teirlinck <teirllm@dms.auburn.edu> noted the context:

	   (info)Help-M

	   which is used in the tutorial, *only* describes menus as
	   they appear in the standalone info, not as they appear in
	   the emacs version and the two are very different.

RMS asked:

   Would you please tell me the specific differences?  I scanned
   through that none and did not notice anything incorrect.

The surface expressions are different depending on the value of
Info-hide-note-references

Most likely you have Info-hide-note-references's value set to nil.
However, the default is to set Info-hide-note-references to t

    *If non-nil, hide the tag and section reference in *note and * menu items.
    Also replaces the "*note" text with "see".
    If value is non-nil but not t, the reference section is still shown.

When you do this, using

    Today's CVS snapshot, Tue, 2003 Jun  3  12:21 lisp UTC
    GNU Emacs 21.3.50.48 (i686-pc-linux-gnu, X toolkit)
    started with

       /usr/local/bin/emacs -q --no-site-file --eval '(blink-cursor-mode 0)'

then the menu in (info)Help-M looks like this.

    * Menu:

    * Foo                  A node you can visit for fun.
    * Bar                  We have made two ways to get to the same place.
    * Help-FOO             And yet another!


But when Info-hide-note-references is set to nil, as it was in the old
days by default, the menu looks like this:

    * Menu:

    * Foo:  Help-FOO.       A node you can visit for fun.
    * Bar:  Help-FOO.       We have made two ways to get to the same place.
    * Help-FOO::            And yet another!

I remember all this because I prefer the old format and remember when
I had to put (setq Info-hide-note-references nil) into my .emacs file.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: Problems with info (emacs version)

[Robert J. Chassell]

Here is another case where different values of
  Info-hide-note-references   lead to different surface expressions in
different buffers.

       I am surprised you think this is such a serious issue.
       Could you provide a test case where it causes a real problem?

    It all depends on what you consider a "real" problem.  If I send
    somebody mail, I like to now exactly what I sent.

When Info-hide-note-references's value is t, 
the Info menu looks like this

  * Emacs Lisp Intro                                       CVS version
  * Elisp                                                  CVS version
  * Emacs                                                  CVS version

which is what Luc Teirlinck <teirllm@dms.auburn.edu> sees in Info.

However, when that segment of the *info* buffer is copied to this
*mail* buffer, the yanked text is this:

  * Emacs Lisp Intro: (/usr/local/src/emacs/info/eintr).   CVS version
  * Elisp: (/usr/local/src/emacs/info/elisp).              CVS version
  * Emacs: (/usr/local/src/emacs/info/emacs).              CVS version

which is also what you see in Info when Info-hide-note-references's
value is nil.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: Problems with info (emacs version)

[Luc Teirlinck]

Robert Chassell wrote:

   The surface expressions are different depending on the value of
   Info-hide-note-references

   Most likely you have Info-hide-note-references's value set to nil.
   However, the default is to set Info-hide-note-references to t

This variable does not seem to be mentioned in the NEWS.  I believe
it should be.

Sincerely,

Luc.

Re: Problems with info (emacs version)

[Simon Josefsson]

Miles Bader <miles@lsi.nec.co.jp> writes:

> Simon Josefsson <jas@extundo.com> writes:
>> > What's wrong with just adding `invisible' to the default list of
>> > properties stripped by yanking?
>> 
>> Could work.  But if, say, message uses the invisible property
>> internally to keep some hidden data around in the buffer, cut'n'paste
>> within the message buffer can generate unexpected result.
>
> Well, does it?  Unless there are real concrete cases where stripping
> invisible would be bad, it seems silly to go around making kludgey
> solutions when such an obvious (and easy) one is staring right at you...

The message-hidden-headers feature uses invisible text.  Perhaps
someone could implement your idea and run with it for a while, to see
if there are other things that use invisible text in message buffers.

Re: Problems with info (emacs version)

[Simon Josefsson]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> 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.

Perhaps it was added in Gnus 5.10.

To clarify: I don't have an opinion on the use of invisible display
property in info, but I object to the example that cut'n'paste text
from the info buffer into a mail buffer is an example of a problem
caused by using the invisible display property in info.  Even if info
didn't use the invisible display property, the message mode must
handle yanking of invisible text.  So all the example proof is that
the message mode is buggy.

Re: Problems with info (emacs version)

[Miles Bader]

On Tue, Jun 03, 2003 at 09:15:57PM +0200, Simon Josefsson wrote:
> The message-hidden-headers feature uses invisible text.  Perhaps
> someone could implement your idea and run with it for a while, to see
> if there are other things that use invisible text in message buffers.

According to other posts in this thread, I was confused -- emacs _already_
strips invisible properties on yank by default (so I guess it's not a
problem!).

-Miles
-- 
Suburbia: where they tear out the trees and then name streets after them.

Re: Problems with info (emacs version)

[Luc Teirlinck]

Simon Josefsson wrote:

   Perhaps it was added in Gnus 5.10.

I guess that would not make David Kastrup happy, for reasons he
explained earlier in this thread.  But I believe that you are
confusing the invisibility property and the display property.  I agree
that message checks for the invisibility property.  The main purposes
of the display property are to change the way text is displayed and to
display pictures.  It can be used to have non-whitespace text
displayed as whitespace, that is "visible" (in the form of whitespace)
but impossible to see.  It is this use of the display property that I
find objectionable and that causes problems.

Sincerely,

Luc.

Re: Problems with info (emacs version)

[Simon Josefsson]

Miles Bader <miles@gnu.org> writes:

> On Tue, Jun 03, 2003 at 09:15:57PM +0200, Simon Josefsson wrote:
>> The message-hidden-headers feature uses invisible text.  Perhaps
>> someone could implement your idea and run with it for a while, to see
>> if there are other things that use invisible text in message buffers.
>
> According to other posts in this thread, I was confused -- emacs _already_
> strips invisible properties on yank by default (so I guess it's not a
> problem!).

Hm.  I frequently yank text from info, and the invisible property does
not seem to be stripped.  To test, I yank part of info dir buffer:

GNU utilities
...
* idn: (libidn)Invoking idn.			      Command line interface to GNU Libidn.

The first line looks bold in this buffer.  The last line looks like "*
idn Command ...".  Same if I yank to *scratch*.  When I send this mail
it will changed into "* idn: (libidn)Invoking idn.  Command ...".

This is with Gnus and message, but I tried M-x mail too and it behaved
the same.

Re: Problems with info (emacs version)

[Luc Teirlinck]

Simon Josefsson wrote:

   Hm.  I frequently yank text from info, and the invisible property does
   not seem to be stripped.  To test, I yank part of info dir buffer:

   GNU utilities
   ...
   * idn: (libidn)Invoking idn.			      Command line interface to GNU Libidn.

   The first line looks bold in this buffer.  The last line looks like "*
   idn Command ...".  Same if I yank to *scratch*.  When I send this mail
   it will changed into "* idn: (libidn)Invoking idn.  Command ...".

   This is with Gnus and message, but I tried M-x mail too and it behaved
   the same.

That is because that text is *not* invisible, but displayed as
whitespace.  Does message-mode really warn about that?

Sincerely,

Luc.

Re: Problems with info (emacs version)

[Simon Josefsson]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Simon Josefsson wrote:
>
>    Hm.  I frequently yank text from info, and the invisible property does
>    not seem to be stripped.  To test, I yank part of info dir buffer:
>
>    GNU utilities
>    ...
>    * idn: (libidn)Invoking idn.			      Command line interface to GNU Libidn.
>
>    The first line looks bold in this buffer.  The last line looks like "*
>    idn Command ...".  Same if I yank to *scratch*.  When I send this mail
>    it will changed into "* idn: (libidn)Invoking idn.  Command ...".
>
>    This is with Gnus and message, but I tried M-x mail too and it behaved
>    the same.
>
> That is because that text is *not* invisible, but displayed as
> whitespace.

Sorry, I misunderstood.

> Does message-mode really warn about that?

No.  Which is a bug. :-)

Re: Problems with info (emacs version)

[Miles Bader]

On Tue, Jun 03, 2003 at 09:46:05PM +0200, Simon Josefsson wrote:
> > According to other posts in this thread, I was confused -- emacs _already_
> > strips invisible properties on yank by default (so I guess it's not a
> > problem!).
> 
> Hm.  I frequently yank text from info, and the invisible property does
> not seem to be stripped.

That's the _other_ part of my confusion in this thread... :-)

Info doesn't use invisibility to hide text, it uses the `display' property to
display whitespace instead.

I think probably message-mode should specifically add `display' the set of
properties stripped by yanking in message-mode buffers -- even less hacky
uses of the display property (such as images) are something the user had
better be aware of when sending email!

Well actually in general, I think it would be nice if message/mail-mode
handled pictures automagically by converting them info an appropriate mime
attachment, in which case probably the right thing to do would be to some how
distinguish betwen the two uses of the display property -- but I think this
should be done at _yank time_, not when sending (as I said before, sending is
too late); is there a hook that runs when something is yanked...?

-Miles
-- 
I have seen the enemy, and he is us.  -- Pogo

Re: Problems with info (emacs version)

[Richard Stallman]

    I am careful, because I like to have exact records of everything I
    mailed, so I FCC to my mail archive file.  Emacs copies:

    * du                 Report on disk usage.
    * echo               Print a line of text.

    to my mail archive file.

That surprises me.  How come the invisible text is not written
to the mail archive file?

Re: Problems with info (emacs version)

[Luc Teirlinck]

Richard Stallman wrote:

       I am careful, because I like to have exact records of everything I
       mailed, so I FCC to my mail archive file.  Emacs copies:

       * du                 Report on disk usage.
       * echo               Print a line of text.

       to my mail archive file.

   That surprises me.  How come the invisible text is not written
   to the mail archive file?

As I already pointed out in a previous message, I confused the mail
archive file with the mail archive buffer.  The invisible text is
indeed written into the mail archive file once you save the buffer.

Sincerely,

Luc.

Re: Problems with info (emacs version)

[Richard Stallman]

      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.

I tend to think that Stefan is right and the property use should be
changed.

Re: Problems with info (emacs version)

[Richard Stallman]

    Inappropriate:

    Using the invisibility properties for internal Emacs purposes.  As the
    various problems I reported show, there is nothing "internal" about
    the invisibility property.

I do not accept that assertion.  The invisible property is meant for
other sorts of usage as well.  However, in this particular case
(info menus), it might be better to remove those characters from the
buffer rather than mark them invisible.

    `display' This property activates various features that change the way
	 text is displayed.  For example, it can make text appear taller
	 or shorter, higher or lower, wider or narrow, or replaced with an
	 image.

    Inappropriate:

    As a way to make text impossible to see, without making it invisible,
    by displaying it as whitespace (as info does extensively), or, more
    generally, as a way to display regular text as some other regular text
    with unrelated content, as an alternative for such lowly tools,
    typically used by the unsophisticated masses, as deletion and
    insertion.

I agree with this one.