mode-line tooltips for "[" and "]" in recursive-edit

mode-line tooltips for "[" and "]" in recursive-edit

[Dan Nicolaescu]

It would be nice if [ and ] that appear in the mode-line in
recursive-edit had a tooltip explaining what they are.  Such tooltips
will be helpful for beginners.

Can someone please add the tooltips?

Thanks!

RE: mode-line tooltips for "[" and "]" in recursive-edit

[Drew Adams]

> It would be nice if [ and ] that appear in the mode-line in
> recursive-edit had a tooltip explaining what they are.  Such tooltips
> will be helpful for beginners.
> 
> Can someone please add the tooltips?

Why do you suggest a change and then, in the same breath, ask someone to go
ahead and install it? Isn't that jumping the gun a bit?

I, for one, think this enhancement would be silly. Tooltips for the
mode-line abound already. Users can read the doc for [].

But my main remark is about your confounding a suggestion with its immediate
implementation. 

Re: mode-line tooltips for "[" and "]" in recursive-edit

[Dan Nicolaescu]

Could you please respect the mail headers? (This is not the fist time
you are doing this).

"Drew Adams" <drew.adams@oracle.com> writes:

  > > It would be nice if [ and ] that appear in the mode-line in
  > > recursive-edit had a tooltip explaining what they are.  Such tooltips
  > > will be helpful for beginners.
  > > 
  > > Can someone please add the tooltips?
  > 
  > Why do you suggest a change and then, in the same breath, ask someone to go
  > ahead and install it? Isn't that jumping the gun a bit?

It is jumping the gun when dealing with someone that just wants to
nitpick.  Someone that wants to cooperate can choose to actually discuss
the idea.

  > I, for one, think this enhancement would be silly. Tooltips for the
  > mode-line abound already. 

The logic here is flawed: the fact that the mode-line has tooltips for
other unrelated items has zero implications about the tooltips for
recursive-edit.  
To explain why this is needed: good UI design provides clues for what
the elements of the UI.  Tooltips are a way to provide such clues, we
use them already.  Suggestions for alternative

  > Users can read the doc for [].

There's no easy way for the users to find those docs.

RE: mode-line tooltips for "[" and "]" in recursive-edit

[Drew Adams]

> Could you please respect the mail headers? (This is not the fist time
> you are doing this).

No idea what you are talking about. I simply hit `Reply All'. I quoted your
message in full (except for the final "Thanks!"). I changed nothing
(consciously) in the message header. What's the problem?

>   > > It would be nice if [ and ] that appear in the mode-line in
>   > > recursive-edit had a tooltip explaining what they are.  
>   > > Such tooltips will be helpful for beginners.
>   > > 
>   > > Can someone please add the tooltips?
>   > 
>   > Why do you suggest a change and then, in the same breath, 
>   > ask someone to go ahead and install it? Isn't that jumping
>   > the gun a bit?
> 
> It is jumping the gun when dealing with someone that just wants to
> nitpick.  Someone that wants to cooperate can choose to 
> actually discuss the idea.

Bof.

I did discuss the idea, even though discussion was hardly invited (and is
apparently hardly appreciated).

>   > I, for one, think this enhancement would be silly. 
>   > Tooltips for the mode-line abound already. 
> 
> The logic here is flawed: the fact that the mode-line has tooltips for
> other unrelated items has zero implications about the tooltips for
> recursive-edit.

Sure, logically there is nothing wrong with adding a tooltip to describe []
- it is independent of other stuff on the mode-line - I agree. I just think
its unnecessary and we don't want to overcharge the mode-line with too many
tooltips. Just one opinion.

To be clear, I have no great objection to your doing this. I just think it
is more noise than real help. I was clear that my post was mainly about your
attitude. If I misread your attitude, I apologize - I may have jumped the
gun, myself, in that regard.

> To explain why this is needed: good UI design provides clues for what
> the elements of the UI.  Tooltips are a way to provide such clues, we
> use them already.  Suggestions for alternative

That describes tooltips in general, and their raison d'etre. It is not an
argument for adding these particular tooltips. 

>   > Users can read the doc for [].
> 
> There's no easy way for the users to find those docs.

OK, go for it. Tooltip away. I don't mind.

Re: mode-line tooltips for "[" and "]" in recursive-edit

[Lennart Borgman (gmail)]

Drew Adams wrote:
>>   > > It would be nice if [ and ] that appear in the mode-line in
>>   > > recursive-edit had a tooltip explaining what they are.  
>>   > > Such tooltips will be helpful for beginners.
...
>> To explain why this is needed: good UI design provides clues for what
>> the elements of the UI.  Tooltips are a way to provide such clues, we
>> use them already.  Suggestions for alternative
> 
> That describes tooltips in general, and their raison d'etre. It is not an
> argument for adding these particular tooltips. 

Some reasons to add tooltips here:

- Those [...] is not there all the time so when they shows up the user 
may wonder, eh, should wonder.
- You may use Emacs for quite some time without seeing them.
- Some things might work strange during recursive editing.
- We have tooltips for other small pieces.
- This tooltip should/could be only on the borders, ie [ and ].

Re: mode-line tooltips for "[" and "]" in recursive-edit

[Dan Nicolaescu]

"Drew Adams" <drew.adams@oracle.com> writes:

  > > Could you please respect the mail headers? (This is not the fist time
  > > you are doing this).
  > 
  > No idea what you are talking about. I simply hit `Reply All'. I quoted your
  > message in full (except for the final "Thanks!"). I changed nothing
  > (consciously) in the message header. What's the problem?

Your mailer does not respect the Mail-Followup-To header then...

RE: mode-line tooltips for "[" and "]" in recursive-edit

[Drew Adams]

>   > > Could you please respect the mail headers? (This is
not 
>   > > the fist time you are doing this).
>   > 
>   > No idea what you are talking about. I simply hit
`Reply 
>   > All'. I quoted your message in full (except for the
>   > final "Thanks!"). I changed nothing (consciously) in
the
>   > message header. What's the problem?
> 
> Your mailer does not respect the Mail-Followup-To header
then...

Whatever. At least you've moved from my supposed
disrespecting to my mailer's supposed disrespecting - thanks
for that.

I see the same header in my replies as in what I receive.
What exactly is the problem that the alleged lack of respect
causes? IOW, before jumping to conclusions about causes,
what is the symptom that is bothering you?

In any case, that reply was no different from all my other
replies, so, no, it was not the first time I was doing this
- I must always be "doing this".

Unless someone can characterize the problem more concretely
and cite an Outlook preference setting that takes care of
it, I guess you'll have to take up the problem with Devil
Gates. Tell him that his mail client is misbehaving.

[OT] Mail-Followup-To, Outlook (was: mode-line tooltips for "[" and "]" in recursive-edit)

[Reiner Steib]

[ We should probably take this off-list? ]

On Fri, Mar 21 2008, Drew Adams wrote:

>> Your mailer does not respect the Mail-Followup-To header
[...]
> IOW, before jumping to conclusions about causes, what is the symptom
> that is bothering you?

The Mail-Followup-To header suggest to whom replies should be
directed.  Then doing a wide reply to Dan's article (with has
"Mail-Followup-To: emacs-devel@gnu.org"), Gnus prompts with the
following explanation:

,----[ *MESSAGE information message* ]
| You should normally obey the Mail-Followup-To: header.  In this
| article, it has the value of
| 
| emacs-devel@gnu.org
| 
| which directs your response to that address only.
| 
| Most commonly, Mail-Followup-To is used by a mailing list poster to
| express that responses should be sent to just the list, and not the
| poster as well.
| 
| If a message is posted to several mailing lists, Mail-Followup-To may
| also be used to direct the following discussion to one list only,
| because discussions that are spread over several lists tend to be
| fragmented and very difficult to follow.
| 
| Also, some source/announcement lists are not intended for discussion;
| responses here are directed to other addresses.
`----

See also <http://cr.yp.to/proto/replyto.html> and
<http://cr.yp.to/immhf/response.html>.  The former URL lists the
following programs as using Mail-Followup-To: qmail, Mutt, nmh,
Shuriken, Gnus, and Kmail.

As it is not a standard and not very widely used, I don't complain
about anyone _not_ respecting it.  Dan's MMV.

> Unless someone can characterize the problem more concretely
> and cite an Outlook preference setting that takes care of
> it, I guess you'll have to take up the problem with Devil
> Gates. Tell him that his mail client is misbehaving.

Wrong.  Probably nobody is forced to use this software when
participating on this mailing list.  More disturbing about your
Outlook 11 is the "Kammquoting"[1].  Well,
`gnus-article-outlook-deuglify-article' in Gnus can fix often fix
it. [2]

Bye, Reiner.

[1] zig-zag-shaped lines that it's hard to read.  See the box on the
    RHS of http://de.wikipedia.org/wiki/Kammquoting or the commentary
    section of `lisp/gnus/deuglify.el'

    In articles <003201c88b5f$c9623670$0600a8c0@us.oracle.com> and
    <003301c88b5f$dd14c8e0$0600a8c0@us.oracle.com> (the article I'm
    replying to).

[2]
,----[ (info "(gnus)Article Washing") ]
| `W Y f'
|      Full deuglify of broken Outlook (Express) articles: Treat
|      dumbquotes, unwrap lines, repair attribution and rearrange
|      citation.  (`gnus-article-outlook-deuglify-article').
`----
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

RE: [OT] Mail-Followup-To, Outlook (was: mode-line tooltips for "[" and "]" in recursive-edit)

[Drew Adams]

> From: Reiner Steib Sent: Friday, March 21, 2008 10:46 AM
> [ We should probably take this off-list? ]

That's not obvious, at this point, since this is about
interacting with the mailing list.

> >> Your mailer does not respect the Mail-Followup-To
header
> [...]
> > IOW, before jumping to conclusions about causes, what is
the symptom
> > that is bothering you?
>
> The Mail-Followup-To header suggest to whom replies should
be
> directed.  Then doing a wide reply to Dan's article (with
has
> "Mail-Followup-To: emacs-devel@gnu.org"), Gnus prompts
with the
> following explanation:
...
> See also <http://cr.yp.to/proto/replyto.html> and
> <http://cr.yp.to/immhf/response.html>.  The former URL
lists the
> following programs as using Mail-Followup-To: qmail, Mutt,
nmh,
> Shuriken, Gnus, and Kmail.

Thanks for the information, Reiner.

Those might be the cat's meow, but with the exception of
Mutt they don't even register on the mail client usage stats
I've seen - e.g.
https://messaging.its.monash.edu.au/stats/client/. Most of
the universe is nonconformist and disrespectful, it seems.
;-)

> As it is not a standard and not very widely used, I don't
complain
> about anyone _not_ respecting it.  Dan's MMV.

In my mailer (still a common one), the two possibilities I
am aware of are Reply and Reply All. The former replies only
to the sender; the latter replies to everyone. I've had
people on the list complain when I didn't use Reply All.
AFAICT, of the two, Reply All seems to lead to fewer
complaints, so far.

> > Unless someone can characterize the problem more
concretely
> > and cite an Outlook preference setting that takes care
of
> > it, I guess you'll have to take up the problem with
Devil
> > Gates. Tell him that his mail client is misbehaving.
>
> Wrong.  Probably nobody is forced to use this software
when
> participating on this mailing list.

Your "probably" is an unwarranted assumption, depending on
how severely one interprets "forced to". I'm using my work
computer with a work mailing address and a work mail client.
I could choose to buy another computer, get another mailing
address, wait until I'm home to answer mail, and so on, so
I'm not strictly "forced to" use Outlook for this list.

Anyway, it sounds as if most of the mail clients in actual
use are misbehaving, if those who behave are limited to
qmail, Mutt, nmh, Shuriken, Gnus, and Kmail. Proclaimed
etiquette and convention are of little use if they are not,
well, actually conventional.

> More disturbing about your
> Outlook 11 is the "Kammquoting"[1].  Well,
> `gnus-article-outlook-deuglify-article' in Gnus can fix
often fix
> it. [2]
>
> [1] zig-zag-shaped lines that it's hard to read.  See the
box on the
>     RHS of http://de.wikipedia.org/wiki/Kammquoting

I don't read German, unfortunately. Googling for just
Kammquoting didn't help either. But I see what you mean from
the box you mention.

>     or the commentary section of `lisp/gnus/deuglify.el'

I looked at deuglify.el too. Kammquoting doesn't seem like a
big deal, to me, but I agree that it is not pretty and
reduces readability. Anyway, AFAICT, my posts and their
wrapped lines are less ugly than a lot of others.

I've reduced the wrap column to 60 - perhaps that will help
a little. Outlook is no doubt primitive, when it comes to
plain-text mail.

BTW, the Commentary in deuglify.el speaks of "illegal"
unwrapping, which is no doubt inappropriate terminology.

>     In articles
<003201c88b5f$c9623670$0600a8c0@us.oracle.com> and
>     <003301c88b5f$dd14c8e0$0600a8c0@us.oracle.com> (the
article I'm
>     replying to).
>
> [2]
> ,----[ (info "(gnus)Article Washing") ]
> | `W Y f'
> |      Full deuglify of broken Outlook (Express) articles:
Treat
> |      dumbquotes, unwrap lines, repair attribution and
rearrange
> |      citation.
(`gnus-article-outlook-deuglify-article').
> `----

Thanks again for educating me.

Re: [OT] Mail-Followup-To, Outlook

[Reiner Steib]

[ Broken citation fixed using ``gnus-article-outlook-deuglify-article' ]

On Fri, Mar 21 2008, Drew Adams wrote:

> Those might be the cat's meow, but with the exception of
> Mutt they don't even register on the mail client usage stats
> I've seen - e.g.
> https://messaging.its.monash.edu.au/stats/client/. 

We are on a mailing list, so I offer a (slightly outdated) statistic
on mailing lists: <http://gmane.org/user-agents.php>.  Mutt, Kmail
and Gnus appear there.  ;-)

> Most of the universe is nonconformist and disrespectful, it seems.
> ;-)

As already explained, Mail-Followup-To is not a standard (yet?):

>> As it is not a standard and not very widely used, I don't complain
>> about anyone _not_ respecting it.  Dan's MMV.
[...]
>> Wrong.  Probably nobody is forced to use this software when
>> participating on this mailing list.
>
> Your "probably" is an unwarranted assumption, depending on
> how severely one interprets "forced to". I'm using my work
> computer with a work mailing address and a work mail client.
> I could choose to buy another computer, 

You could post via Gmane.org
<http://news.gmane.org/gmane.emacs.devel/> without installing any new
program.

That said, I don't care what client you use.  If most of your postings
look like the recent ones, I will just adjust my score file and not
read your articles anymore.  (This is not supposed to be a threat
against you; it's just how I always handle this.)

> get another mailing address, wait until I'm home to answer mail, and
> so on, so I'm not strictly "forced to" use Outlook for this list.

[...]

> I looked at deuglify.el too. Kammquoting doesn't seem like a
> big deal, to me, but I agree that it is not pretty and
> reduces readability. 

It's no problem at all for users of Outlook (Express), but for
everyone else.

> Anyway, AFAICT, my posts and their wrapped lines are less ugly than
> a lot of others.

?

> I've reduced the wrap column to 60 - perhaps that will help
> a little. 

Maybe this made it worse.  At least, today was the first time I recall
that your articles contain so much "Kammquoting".

> BTW, the Commentary in deuglify.el speaks of "illegal"
> unwrapping, which is no doubt inappropriate terminology.

Already fixed in CVS (trunk and Emacs 22.2): "invalid"

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: [OT] Mail-Followup-To, Outlook

[Stefan Monnier]

Could you guys move this elsewhere?

Thank you,


        Stefan

RE: mode-line tooltips for "[" and "]" in recursive-edit

[Stephen J. Turnbull]

Drew Adams writes:

 > Unless someone can characterize the problem more concretely
 > and cite an Outlook preference setting that takes care of
 > it, I guess you'll have to take up the problem with Devil
 > Gates. Tell him that his mail client is misbehaving.

No need to.  It's well-known that Outlook is non-conforming in several
ways, and I for one believe it to be deliberate sabotage of
non-Outlook, non-Exchange mail systems based on the huge market
penetration that "Lookout" behavior has achieved based on "Lookout,
Excess!" being distributed as part of the OS.

However, in the case of the Mail-Followup-To header, ignoring it is
conforming to the existing standards (including the standards-track
RFCs)[1], unless you have agreed in advance to respect it.  Neither
you nor Bill have done so, so Dan is out of luck.

Nevertheless-friends-don't-let-friends-use-Outlook-ly y'rs,

Footnotes: 
[1]  To the best of my knowledge, which is somewhat dated at this
point, but is corroborated by a search of the RFC database.

Re: mode-line tooltips for "[" and "]" in recursive-edit

[Stephen J. Turnbull]

Dan Nicolaescu writes:

 > Your mailer does not respect the Mail-Followup-To header then...

No, and there's no standard saying a *mailer* should.  That's not a
Mail header, it's a News header, intended to redirect traffic from
Usenet to mail.  AFAIK it was first proposed to be added to the mail
standards more than a decade ago, and it has repeatedly failed even to
get out of committee.

(N.B.  I last checked this about two years ago, but I see no reason to
suppose the status has changed since then.)

Granted, it would be a nice feature if the proponents could get their
collective act together and get an RFC out the door, but with no
standard, what is an implementer supposed to do?  The Internet
standards themselves say pre-RFC headers should only be used by
parties who have agreed to do so ... and that apparently doesn't apply
to Drew.

Mail-Followup-To (was: mode-line tooltips for "[" and "]" in recursive-edit)

[Reiner Steib]

On Fri, Mar 21 2008, Stephen J. Turnbull wrote:

> Dan Nicolaescu writes:
>
>  > Your mailer does not respect the Mail-Followup-To header then...
>
> No, and there's no standard saying a *mailer* should.  That's not a
> Mail header, it's a News header, intended to redirect traffic from
> Usenet to mail.  

Mail-Followup-To is for mail messages.  See
e.g. <http://cr.yp.to/proto/replyto.html>

> Granted, it would be a nice feature if the proponents could get their
> collective act together and get an RFC out the door, 

Agreed.

> but with no standard, what is an implementer supposed to do?  The
> Internet standards themselves say pre-RFC headers should only be
> used by parties who have agreed to do so ... and that apparently
> doesn't apply to Drew.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Mail-Followup-To

[Stephen J. Turnbull]

Reiner Steib writes:

 > Mail-Followup-To is for mail messages.  See
 > e.g. <http://cr.yp.to/proto/replyto.html>

With all due respect to Professor Bernstein, his home page is not on
the standards track, and his page on reply-to is not even close to
being useful for a standard because it doesn't say when to generate
those headers, or who may generate them.  IIRC, the standards track
proposals I've seen all generalized it to news, and agree on how to
specify it for news, but not for mail.  Gnus itself claims conformance
to an ancient expired internet-draft, not Bernstein's proposal, AFAIK.

I agree that emacs-devel posters should be encouraged to consider
using MUAs that respect M-F-T, or adding it to their MUAs.  But this
is a matter of "courtesy beyond the call of duty", not of standard
conformance.

Re: Mail-Followup-To

[Reiner Steib]

On Sat, Mar 22 2008, Stephen J. Turnbull wrote:

> Reiner Steib writes:
>
>  > Mail-Followup-To is for mail messages.  See
>  > e.g. <http://cr.yp.to/proto/replyto.html>
>
> With all due respect to Professor Bernstein, his home page is not on
> the standards track, 

I didn't say anything like this.  This page just happens to be one of
the first Google hits.

> and his page on reply-to is not even close to being useful for a
> standard because it doesn't say when to generate those headers, or
> who may generate them.  IIRC, the standards track proposals I've
> seen all generalized it to news, and agree on how to specify it for
> news, but not for mail.  

I don't know if you refer to
draft-ietf-drums-mail-followup-to-00.txt[1].  This document primarily
talk about mail (mailing lists), except for "2.5 Usenet News Client
Action".

,----[ draft-ietf-drums-mail-followup-to-00.txt ]
| Abstract
| 
| This proposal contains a proposed new e-mail header ''Mail-Followup-To'',
| which is intended to be used instead of the ''Reply-To'' header for
| suggesting where replies to the group who participates in a discussion
| should be sent.
`----

> I agree that emacs-devel posters should be encouraged to consider
> using MUAs that respect M-F-T, or adding it to their MUAs.  But this
> is a matter of "courtesy beyond the call of duty", not of standard
> conformance.

Agreed.

Bye, Reiner.

[1] <http://www.ietf.org/proceedings/98dec/I-D/draft-ietf-drums-mail-followup-to-00.txt>
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: mode-line tooltips for "[" and "]" in recursive-edit

[Jan Djärv]

Dan Nicolaescu skrev:
> Could you please respect the mail headers? (This is not the fist time
> you are doing this).
> 
> "Drew Adams" <drew.adams@oracle.com> writes:
> 
>   > > It would be nice if [ and ] that appear in the mode-line in
>   > > recursive-edit had a tooltip explaining what they are.  Such tooltips
>   > > will be helpful for beginners.
>   > > 
>   > > Can someone please add the tooltips?
>   > 
>   > Why do you suggest a change and then, in the same breath, ask someone to go
>   > ahead and install it? Isn't that jumping the gun a bit?
> 
> It is jumping the gun when dealing with someone that just wants to
> nitpick.  Someone that wants to cooperate can choose to actually discuss
> the idea.
> 
>   > I, for one, think this enhancement would be silly. Tooltips for the
>   > mode-line abound already. 
> 
> The logic here is flawed: the fact that the mode-line has tooltips for
> other unrelated items has zero implications about the tooltips for
> recursive-edit.  
> To explain why this is needed: good UI design provides clues for what
> the elements of the UI.  Tooltips are a way to provide such clues, we
> use them already.

But it is very annoying with all this new tool tips when you have 
tooltip-use-echo-area set to t.  The minibuffer expands and shrinks for 
multiline tooltips just because you happen to pass the modeline with the pointer.

Is there a way to turn off modeline tooltips?  I think that would be useful.

	Jan D.

Re: mode-line tooltips for "[" and "]" in recursive-edit

[Nick Roberts]

 > But it is very annoying with all this new tool tips when you have
 > tooltip-use-echo-area set to t.  The minibuffer expands and shrinks for
 > multiline tooltips just because you happen to pass the modeline with the
 > pointer.

Likewise, I went to a lot of trouble to get tooltips to work on the console
where they always appear in the mini-buffer (they don't currently work in
the mode-line but could be made to do so).

 > Is there a way to turn off modeline tooltips?  I think that would be useful.

Apparently they are meant to "help newbies" so it's ironic that they might
need to learn how to turn them off.

At the risk of being disabused by Dan, I would suggest that these tooltips are
reverted to single line tips.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: mode-line tooltips for "[" and "]" in recursive-edit

[Lennart Borgman (gmail)]

Nick Roberts wrote:
>  > But it is very annoying with all this new tool tips when you have
>  > tooltip-use-echo-area set to t.  The minibuffer expands and shrinks for
>  > multiline tooltips just because you happen to pass the modeline with the
>  > pointer.
> 
> Likewise, I went to a lot of trouble to get tooltips to work on the console
> where they always appear in the mini-buffer (they don't currently work in
> the mode-line but could be made to do so).
> 
>  > Is there a way to turn off modeline tooltips?  I think that would be useful.
> 
> Apparently they are meant to "help newbies" so it's ironic that they might
> need to learn how to turn them off.
> 
> At the risk of being disabused by Dan, I would suggest that these tooltips are
> reverted to single line tips.

Convert them to single line tips always when tooltip-use-echo-area is t 
perhaps?

Re: mode-line tooltips for "[" and "]" in recursive-edit

[Nick Roberts]

 > Convert them to single line tips always when tooltip-use-echo-area is t 
 > perhaps?

Please do that then.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: mode-line tooltips for "[" and "]" in recursive-edit

[Juri Linkov]

>  > Convert them to single line tips always when tooltip-use-echo-area is t
>  > perhaps?
>
> Please do that then.

And please do the same when tooltip-use-echo-area is nil and
tooltip-mode is nil (currently only the first line of the tooltip
is displayed in the echo-area in this case).

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: mode-line tooltips for "[" and "]" in recursive-edit

[Jan Djärv]

Juri Linkov skrev:
>>  > Convert them to single line tips always when tooltip-use-echo-area is t
>>  > perhaps?
>>
>> Please do that then.
> 
> And please do the same when tooltip-use-echo-area is nil and
> tooltip-mode is nil (currently only the first line of the tooltip
> is displayed in the echo-area in this case).
> 

I've added a general mechanism that converts multiline tooltips to single line 
in this case.  Maybe it should be customizable, but if you want multiline 
tooltips, you can always use the normal tooltip mode (i.e. not the echo area).

BTW, When I display a normal tooltip for the first time after Emacs has been 
started, it is always only the first line.  After that, all lines are 
displayed correctly.  Does anybody else see this?

	Jan D.

Re: mode-line tooltips for "[" and "]" in recursive-edit

[Nick Roberts]

 > I've added a general mechanism that converts multiline tooltips to single
 > line in this case.  Maybe it should be customizable, but if you want
 > multiline tooltips, you can always use the normal tooltip mode (i.e. not the
 > echo area).

Now it seems to just display the first line which often doesn't include the
most interesting information.


 > BTW, When I display a normal tooltip for the first time after Emacs has been 
 > started, it is always only the first line.  After that, all lines are 
 > displayed correctly.  Does anybody else see this?

Yes, I have noticed this too on:

GNU Emacs 23.0.60.66 (i686-pc-linux-gnu, GTK+ Version 2.10.11)

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: mode-line tooltips for "[" and "]" in recursive-edit

[Jan Djärv]

Nick Roberts skrev:
>  > I've added a general mechanism that converts multiline tooltips to single
>  > line in this case.  Maybe it should be customizable, but if you want
>  > multiline tooltips, you can always use the normal tooltip mode (i.e. not the
>  > echo area).
> 
> Now it seems to just display the first line which often doesn't include the
> most interesting information.

Basically it takes the multiline tool tip and join lines to a single line 
until no more lines can be added without exceeding the frame width.

The idea is that if you are sofisticated enough to disable tool tips, you 
either know what they say or don't care that much.  But the main thing is to 
avoid minibuffer expansion and shrinkage.

I find that I do get the interesting information, for example

"Buffer is read-only, mouse-1 toggles"
"Buffer coding system (multi-byte): utf-8-unix, mouse-1: describe coding system"
"Buffer is Modified, mouse-1 toggles modified state"

If you are just seeing the first line ("Buffer is Modified") then you didn't 
recompile all .el files correctly.

	Jan D.

Re: mode-line tooltips for "[" and "]" in recursive-edit

[Nick Roberts]

 > If you are just seeing the first line ("Buffer is Modified") then you didn't 
 > recompile all .el files correctly.

Yes, you're right.  Some of the lines are a bit wide now that the tooltips have
longer messages, but it's a big improvement.

Is it easy to make the console work the same way? (mode-line tooltips don't
currently display there but they will one day).

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: mode-line tooltips for "[" and "]" in recursive-edit

[Jan Djärv]

Nick Roberts skrev:
>  > If you are just seeing the first line ("Buffer is Modified") then you didn't 
>  > recompile all .el files correctly.
> 
> Yes, you're right.  Some of the lines are a bit wide now that the tooltips have
> longer messages, but it's a big improvement.
> 
> Is it easy to make the console work the same way? (mode-line tooltips don't
> currently display there but they will one day).
> 

I guess it wouldn't be hard at all.

	Jan D.

RE: mode-line tooltips for "[" and "]" in recursive-edit

[Drew Adams]

> Basically it takes the multiline tool tip and join lines to a 
> single line until no more lines can be added without exceeding
> the frame width.
> 
> The idea is that if you are sofisticated enough to disable 
> tool tips, you either know what they say or don't care that
> much.

Don't be silly. Disabling tooltip-mode implies nothing about not wanting to see
the tooltip help.

If the idea was that people disabling the popup window don't want to see the
help at all, then the behavior would not be to show the help in the minibuffer.

> But the main thing is to avoid minibuffer expansion and shrinkage.

Why is that the main thing? Why is that even a goal?

Re: mode-line tooltips for "[" and "]" in recursive-edit

[Stefan Monnier]

>> But the main thing is to avoid minibuffer expansion and shrinkage.
> Why is that the main thing? Why is that even a goal?

Because some people don't like it or because it sometimes can't be done.
I think this is a very good change,


        Stefan

RE: mode-line tooltips for "[" and "]" in recursive-edit

[Drew Adams]

> >> But the main thing is to avoid minibuffer expansion and shrinkage.
> >
> > Why is that the main thing? Why is that even a goal?
> 
> Because some people don't like it or because it sometimes 
> can't be done.

If it can't be done, then it can't be done. Can't argue with that.

But it doesn't seem right for the only echo-area display of tooltip help to
truncate it at the frame width. Joining the lines is not a problem, but losing
some of the info could be.

Make such truncation an option, if you want, and even make it the default way of
displaying a tooltip in the echo area, if you want. But there should be some way
for users to see the complete tooltip text in the echo area.

Re: mode-line tooltips for "[" and "]" in recursive-edit

[Stefan Monnier]

>> >> But the main thing is to avoid minibuffer expansion and shrinkage.
>> >
>> > Why is that the main thing? Why is that even a goal?
>> 
>> Because some people don't like it or because it sometimes 
>> can't be done.

> If it can't be done, then it can't be done. Can't argue with that.

> But it doesn't seem right for the only echo-area display of tooltip
> help to truncate it at the frame width. Joining the lines is not
> a problem, but losing some of the info could be.

> Make such truncation an option, if you want, and even make it the
> default way of displaying a tooltip in the echo area, if you want. But
> there should be some way for users to see the complete tooltip text in
> the echo area.

Oh, you're arguing about the truncation part, not the single-line part.
Then I agree it might be better to not bother truncating.
Especially since the truncation is inexact anyway (depending on the
chars found and the fonts used for them we may not cut at the right
place: the only right way to truncate is via tuncate-lines).


        Stefan

Re: mode-line tooltips for "[" and "]" in recursive-edit

[Jan Djärv]

Stefan Monnier skrev:
>>>>> But the main thing is to avoid minibuffer expansion and shrinkage.
>>>> Why is that the main thing? Why is that even a goal?
>>> Because some people don't like it or because it sometimes 
>>> can't be done.
> 
>> If it can't be done, then it can't be done. Can't argue with that.
> 
>> But it doesn't seem right for the only echo-area display of tooltip
>> help to truncate it at the frame width. Joining the lines is not
>> a problem, but losing some of the info could be.
> 
>> Make such truncation an option, if you want, and even make it the
>> default way of displaying a tooltip in the echo area, if you want. But
>> there should be some way for users to see the complete tooltip text in
>> the echo area.
> 
> Oh, you're arguing about the truncation part, not the single-line part.
> Then I agree it might be better to not bother truncating.

If you don't truncate, you can't get single line.

> Especially since the truncation is inexact anyway (depending on the
> chars found and the fonts used for them we may not cut at the right
> place: the only right way to truncate is via tuncate-lines).
> 

Truncate happens at newlines.  I thought it best to show complete lines rather 
than lines cut at some random word.

	Jan D.

Re: mode-line tooltips for "[" and "]" in recursive-edit

[Jan Djärv]

Jan Djärv skrev:
> 
> 
> Stefan Monnier skrev:
>>>>>> But the main thing is to avoid minibuffer expansion and shrinkage.
>>>>> Why is that the main thing? Why is that even a goal?
>>>> Because some people don't like it or because it sometimes can't be
>>>> done.
>>
>>> If it can't be done, then it can't be done. Can't argue with that.
>>
>>> But it doesn't seem right for the only echo-area display of tooltip
>>> help to truncate it at the frame width. Joining the lines is not
>>> a problem, but losing some of the info could be.
>>
>>> Make such truncation an option, if you want, and even make it the
>>> default way of displaying a tooltip in the echo area, if you want. But
>>> there should be some way for users to see the complete tooltip text in
>>> the echo area.
>>
>> Oh, you're arguing about the truncation part, not the single-line part.
>> Then I agree it might be better to not bother truncating.
> 
> If you don't truncate, you can't get single line.

You can get a single line of text in a minibuffer that is just one line if
message-truncate-lines is t, so that is what it does now.  Thanks for the
truncate-line hint.   But I don't get it, you still can't sidescroll in the
minibuffer, so some of the text is unavailable anyway.

	Jan D.

Re: mode-line tooltips for "[" and "]" in recursive-edit

[Stefan Monnier]

>> Especially since the truncation is inexact anyway (depending on the
>> chars found and the fonts used for them we may not cut at the right
>> place: the only right way to truncate is via tuncate-lines).
> Truncate happens at newlines.

I understand the intention, but Emacs is notoriously bad at relating
string-sizes and window-sizes, so your comparison of text-size with
window-width just can't be foolproof: you'll get cases where you think
you cut the line short enough, but it wraps onto the next line anyway
because the fonts are bigger.  And other cases where you end up cutting
shorter than you'd have to.

> I thought it best to show complete lines rather than lines cut at some
> random word.

But it's also good for the user to know that there's more to it.
And if he decided to keep it all on a single-line, he's probably willing
to deal with some side effects.


        Stefan

Re: mode-line tooltips for "[" and "]" in recursive-edit

[Jan Djärv]

Drew Adams skrev:
>> Basically it takes the multiline tool tip and join lines to a 
>> single line until no more lines can be added without exceeding
>> the frame width.
>>
>> The idea is that if you are sofisticated enough to disable 
>> tool tips, you either know what they say or don't care that
>> much.
> 
> Don't be silly. Disabling tooltip-mode implies nothing about not wanting to see
> the tooltip help.

It does for me.

> 
> If the idea was that people disabling the popup window don't want to see the
> help at all, then the behavior would not be to show the help in the minibuffer.
> 
>> But the main thing is to avoid minibuffer expansion and shrinkage.
> 
> Why is that the main thing? Why is that even a goal?
> 

Because Emacs didn't do that before people started adding long multiline 
tooltips.  Because it is annoying.  If you donät like it, implement something 
that satisfies everybody,

	Jan D.

RE: mode-line tooltips for "[" and "]" in recursive-edit

[Drew Adams]

> >> Basically it takes the multiline tool tip and join lines to a 
> >> single line until no more lines can be added without exceeding
> >> the frame width.
> >>
> >> The idea is that if you are sofisticated enough to disable 
> >> tool tips, you either know what they say or don't care that
> >> much.
> > 
> > Don't be silly. Disabling tooltip-mode implies nothing 
> > about not wanting to see the tooltip help.
> 
> It does for me.

According to the doc string and the behavior of tooltip-mode, when disabled it
shows the help text in the echo area. That is not a matter of personal
preference or opinion; it is what disabling tooltip-mode _means_.

How do you infer from this definition that users who disable the mode do not
want to see the help text? You might infer that they don't want to see it in a
popup window, but not that they never want to see it.

> >> But the main thing is to avoid minibuffer expansion and shrinkage.
> > 
> > Why is that the main thing? Why is that even a goal?

BTW, I asked that because no reason at all was given. Proposals need reasons.

> Because Emacs didn't do that

Didn't do what? Show the complete text in the echo area? Resize the minibuffer?

> before people started adding long multiline tooltips.

Either (1) those added tooltips should not be so long (so no problem) or (2)
their text deserves to be displayed. Either the longer text has a raison d'etre
or it doesn't. If you think it doesn't, then shorten it.

> Because it is annoying.
> If you donät like it, implement something that satisfies everybody

You're the one proposing a change, not I.

Your proposal truncates the help text for users who choose to see it in the echo
area. That shouldn't be imposed - it could be an option, but users should be
able to get the complete text if they want, no matter which display method is
used.

Re: mode-line tooltips for "[" and "]" in recursive-edit

[Jan Djärv]

Drew Adams skrev:

> According to the doc string and the behavior of tooltip-mode, when disabled it
> shows the help text in the echo area. That is not a matter of personal
> preference or opinion; it is what disabling tooltip-mode _means_.

No, it is how it *behaves*, it does not imply any consious though.  Consious 
though is done by users.

> 
> How do you infer from this definition that users who disable the mode do not
> want to see the help text? You might infer that they don't want to see it in a
> popup window, but not that they never want to see it.

You are the only one complaining feel free to implement your scheme but be 
sure that the default is the way it is now, because more people like it than 
dislike it (AFAIK, you are the only one).  Code is so much better that ranting.

	Jan D.

Re: mode-line tooltips for "[" and "]" in recursive-edit

[Juri Linkov]

> It would be nice if [ and ] that appear in the mode-line in
> recursive-edit had a tooltip explaining what they are.  Such tooltips
> will be helpful for beginners.
>
> Can someone please add the tooltips?

This could be done with the following patch:

Index: lisp/bindings.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/bindings.el,v
retrieving revision 1.198
diff -c -r1.198 bindings.el
*** lisp/bindings.el	5 Mar 2008 04:09:24 -0000	1.198
--- lisp/bindings.el	20 Mar 2008 23:56:29 -0000
***************
*** 345,351 ****
  	 (propertize "-%-" 'help-echo help-echo)))
         (standard-mode-line-modes
  	(list
! 	 (propertize "%[(" 'help-echo help-echo)
  	 `(:propertize ("" mode-name)
  		       help-echo "Major mode\n\
  mouse-1: Display major mode menu\n\
--- 345,352 ----
  	 (propertize "-%-" 'help-echo help-echo)))
         (standard-mode-line-modes
  	(list
! 	 (propertize "%[" 'help-echo "Recursive edit, type C-M-c to get out")
! 	 (propertize "(" 'help-echo help-echo)
  	 `(:propertize ("" mode-name)
  		       help-echo "Major mode\n\
  mouse-1: Display major mode menu\n\
***************
*** 365,371 ****
  		     'mouse-face 'mode-line-highlight
  		     'local-map (make-mode-line-mouse-map
  				 'mouse-2 #'mode-line-widen))
! 	 (propertize ")%]--" 'help-echo help-echo)))
  
         (standard-mode-line-position
  	`((-3 ,(propertize
--- 366,374 ----
  		     'mouse-face 'mode-line-highlight
  		     'local-map (make-mode-line-mouse-map
  				 'mouse-2 #'mode-line-widen))
! 	 (propertize ")" 'help-echo help-echo)
! 	 (propertize "%]" 'help-echo "Recursive edit, type C-M-c to get out")
! 	 (propertize "--" 'help-echo help-echo)))
  
         (standard-mode-line-position
  	`((-3 ,(propertize

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: mode-line tooltips for "[" and "]" in recursive-edit

[Dan Nicolaescu]

Juri Linkov <juri@jurta.org> writes:

  > > It would be nice if [ and ] that appear in the mode-line in
  > > recursive-edit had a tooltip explaining what they are.  Such tooltips
  > > will be helpful for beginners.
  > >
  > > Can someone please add the tooltips?
  > 
  > This could be done with the following patch:

Great, thank you!