Bug in change in button.el?

Bug in change in button.el?

[Richard Stallman]

     ;; Use color for the MS-DOS port because it doesn't support underline.
    -(defface button '((((type pc) (class color))
    +;; Also for the linux console.
    +(defface button '((((type pc tty) (class color))

Doesn't "tty" include xterms?  If so, it will give the wrong results
on xterms that can underline.

Re: Bug in change in button.el?

[Glenn Morris]

Richard Stallman wrote:

>      ;; Use color for the MS-DOS port because it doesn't support underline.
>     -(defface button '((((type pc) (class color))
>     +;; Also for the linux console.
>     +(defface button '((((type pc tty) (class color))
>
> Doesn't "tty" include xterms?  If so, it will give the wrong results
> on xterms that can underline.

Nick already changed it, for this very reason I think.

Re: Bug in change in button.el?

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Mon, 23 Apr 2007 19:15:50 -0400
> Cc: emacs-devel@gnu.org
> 
> Richard Stallman wrote:
> 
> >      ;; Use color for the MS-DOS port because it doesn't support underline.
> >     -(defface button '((((type pc) (class color))
> >     +;; Also for the linux console.
> >     +(defface button '((((type pc tty) (class color))
> >
> > Doesn't "tty" include xterms?  If so, it will give the wrong results
> > on xterms that can underline.
> 
> Nick already changed it, for this very reason I think.

Actually, I think we should not have touched this at all.  Face
definitions are frail; it took us a long time during development to
get to the current consensus.  It's beyond me why Nick, who was afraid
of Miles tweaking CVS comments, went ahead and made a much more
sensitive change.

Re: Bug in change in button.el?

[Richard Stallman]

    >      ;; Use color for the MS-DOS port because it doesn't support underline.
    >     -(defface button '((((type pc) (class color))
    >     +;; Also for the linux console.
    >     +(defface button '((((type pc tty) (class color))
    >
    > Doesn't "tty" include xterms?  If so, it will give the wrong results
    > on xterms that can underline.

    Nick already changed it, for this very reason I think.

Do you mean the change to inherit from `link'?
I thought we did not want buttons to look just like links.
Also, what the definition of `link' does is use color and underlining
together, although each one of them works only when supported.

Re: Bug in change in button.el?

[Glenn Morris]

Richard Stallman wrote:

> Do you mean the change to inherit from `link'?
> I thought we did not want buttons to look just like links.
> Also, what the definition of `link' does is use color and underlining
> together, although each one of them works only when supported.

Then I guess this change is better. The (type pc) test can be removed
if MS-DOS correctly answers the (supports) question.


*** button.el	23 Apr 2007 03:32:12 -0000	1.27
--- button.el	24 Apr 2007 22:00:18 -0000
***************
*** 52,62 ****
  ;; Globals
  
  ;; Use color for the MS-DOS port because it doesn't support underline.
- ;; Also for the linux console.
  (defface button '((((type pc) (class color))
  		   (:foreground "lightblue"))
! 		  (((type tty)) (:inherit link))
! 		  (t :underline t))
    "Default face used for buttons."
    :group 'basic-faces)
  
--- 52,61 ----
  ;; Globals
  
  ;; Use color for the MS-DOS port because it doesn't support underline.
  (defface button '((((type pc) (class color))
  		   (:foreground "lightblue"))
! 		  (((supports :underline t)) :underline t)
! 		  (t (:foreground "lightblue")))
    "Default face used for buttons."
    :group 'basic-faces)

Re: Bug in change in button.el?

[Nick Roberts]

 > > Do you mean the change to inherit from `link'?
 > > I thought we did not want buttons to look just like links.
 > > Also, what the definition of `link' does is use color and underlining
 > > together, although each one of them works only when supported.
 > 
 > Then I guess this change is better. The (type pc) test can be removed
 > if MS-DOS correctly answers the (supports) question.

But this seems a bit tortuous.  If we want to do this, button might as well
just inherit from the underline face.

 > *** button.el	23 Apr 2007 03:32:12 -0000	1.27
 > --- button.el	24 Apr 2007 22:00:18 -0000
 > ***************
 > *** 52,62 ****
 >   ;; Globals
 >   
 >   ;; Use color for the MS-DOS port because it doesn't support underline.
 > - ;; Also for the linux console.
 >   (defface button '((((type pc) (class color))
 >   		   (:foreground "lightblue"))
 > ! 		  (((type tty)) (:inherit link))
 > ! 		  (t :underline t))
 >     "Default face used for buttons."
 >     :group 'basic-faces)
 >   
 > --- 52,61 ----
 >   ;; Globals
 >   
 >   ;; Use color for the MS-DOS port because it doesn't support underline.
 >   (defface button '((((type pc) (class color))
 >   		   (:foreground "lightblue"))
 > ! 		  (((supports :underline t)) :underline t)
 > ! 		  (t (:foreground "lightblue")))
 >     "Default face used for buttons."
 >     :group 'basic-faces)
 >   
 > 
 > 
 > 
 > _______________________________________________
 > Emacs-devel mailing list
 > Emacs-devel@gnu.org
 > http://lists.gnu.org/mailman/listinfo/emacs-devel

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

Re: Bug in change in button.el?

[Lennart Borgman (gmail)]

Nick Roberts wrote:
>  > > Do you mean the change to inherit from `link'?
>  > > I thought we did not want buttons to look just like links.
>  > > Also, what the definition of `link' does is use color and underlining
>  > > together, although each one of them works only when supported.
>  > 
>  > Then I guess this change is better. The (type pc) test can be removed
>  > if MS-DOS correctly answers the (supports) question.
> 
> But this seems a bit tortuous.  If we want to do this, button might as well
> just inherit from the underline face.


The default button usage is AFAICS a link. Then it seems natural to me 
that the default face for button is link.

We discussed that before, but I think it was deemed "to close to the 
release" (though I do not remember the reason for sure any more). 
However if any change is going to be made now I propose what I said above.

RE: Bug in change in button.el?

[Drew Adams]

> > But this seems a bit tortuous.  If we want to do this, button
> > might as well just inherit from the underline face.
>
> The default button usage is AFAICS a link. Then it seems natural to me
> that the default face for button is link.
>
> We discussed that before, but I think it was deemed "to close to the
> release" (though I do not remember the reason for sure any more).
> However if any change is going to be made now I propose what I said above.

I really don't want to get involved in this discussion, and I have not been
following it well. I assumed this was only about MSDOS.

However, if you are now deciding general things about the appearance of
buttons and links, I'd say (once again) that users should generally be able
to distinguish buttons from links by looking at them. Buttons should not, in
general, look like links.

Users should be able to expect that clicking a link takes them somewhere and
clicking a button performs some action (other than what a link does).
Preferably, users should have some idea where a given link leads and what
action a given button performs.

This doesn't say much about how things must be implemented, of course.

Re: Bug in change in button.el?

[Miles Bader]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> We discussed that before, but I think it was deemed "to close to the
> release"

AFAICT, the rule has changed in the last few days to "do whatever random
crap I want without discussion."

-Miles

-- 
o The existentialist, not having a pillow, goes everywhere with the book by
  Sullivan, _I am going to spit on your graves_.

Re: Bug in change in button.el?

[Nick Roberts]

Miles Bader writes:
 > "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
 > > We discussed that before, but I think it was deemed "to close to the
 > > release"
 > 
 > AFAICT, the rule has changed in the last few days to "do whatever random
 > crap I want without discussion."

My intention was to address a single issue: make links in a help buffer visible
on a linux console - it was preceded by several e-mails.  Lennart has added
false assumptions, that make it appear to be a discussion about the general
appearance of a link.  At the risk of starting a another pointless thread, I
think that often posts from some subscribers need to be filtered out of the
discussion.

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

Re: Bug in change in button.el?

[Lennart Borgman (gmail)]

Nick Roberts wrote:

> My intention was to address a single issue: make links in a help buffer visible
> on a linux console - it was preceded by several e-mails.  Lennart has added
> false assumptions, that make it appear to be a discussion about the general
> appearance of a link.

Yes, I thought you were interested in seeing any links regardless of 
buffer mode on a linux console.

Re: Bug in change in button.el?

[Glenn Morris]

Nick Roberts wrote:

> But this seems a bit tortuous. If we want to do this, button might
> as well just inherit from the underline face.

Why is is tortuous to say "use underline if supported, else try colour"?

If it inherits from underline, it will use either underline or bold,
so that's different yet again.

My suggestion would (I think) get the behaviour you initially wanted;
ie colour when underlining does not work. And a colour already
extensively used on MS-DOS, so it must be OK.

Otherwise let's just go back to how it was originally, with
indistinguishable buttons on the linux console.

Re: Bug in change in button.el?

[Nick Roberts]

 > > But this seems a bit tortuous. If we want to do this, button might
 > > as well just inherit from the underline face.
 > 
 > Why is is tortuous to say "use underline if supported, else try colour"?

So Emacs is consistent in what it does when underlining is not supported.

 > If it inherits from underline, it will use either underline or bold,
 > so that's different yet again.

Previously it did nothing (apart from on MS-DOS), bold (if available) would
be fine.  However I don't quite understand the specification because it
seems to default to :underline when neither underline or bold are supported.

(defface underline
  '((((supports :underline t))
     :underline t)
    (((supports :weight bold))
     :weight bold)
    (t :underline t))
  "Basic underlined face."
  :group 'basic-faces)

 > My suggestion would (I think) get the behaviour you initially wanted;
 > ie colour when underlining does not work. And a colour already
 > extensively used on MS-DOS, so it must be OK.
 > 
 > Otherwise let's just go back to how it was originally, with
 > indistinguishable buttons on the linux console.

No let's sort this case, and leave behaviour otherwise unchanged.  RMS can
decide which solution to use.

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

Re: Bug in change in button.el?

[Glenn Morris]

Nick Roberts wrote:

> So Emacs is consistent in what it does when underlining is not
> supported.

It's only "consistent" if you really want this to be an underlined
face. If you actually want it to be distinguishable, it should use
something else (eg colour).

> Previously it did nothing (apart from on MS-DOS), bold (if
> available) would be fine.

I can tell you by experiment that if you make it inherit from
underline, it will once again by indistinguishable on the linux
console.

> No let's sort this case, and leave behaviour otherwise unchanged.

Absolutely!

> RMS can decide which solution to use.

Decide between what choices?


I do think this needed changing, because buttons were
indistinguishable on the console as you said. I really regret that I
got it wrong and spawned yet another big discussion on a small issue.
Sorry all.

Re: Bug in change in button.el?

[Miles Bader]

Glenn Morris <rgm@gnu.org> writes:
> I can tell you by experiment that if you make it inherit from
> underline, it will once again by indistinguishable on the linux
> console.

Are you sure that you have TERM set correctly (to "linux")?

On my system the "underline" face displays as expected on the linux
console:  it uses bold because there's no underline support.

Here's what display-supports-face-attributes-p says for the linux console:

   (display-supports-face-attributes-p '(:underline t))
     => nil
   (display-supports-face-attributes-p '(:weight bold))
     => t

If you're using the correct TERM, what do these return for you?

-Miles

-- 
Any man who is a triangle, has thee right, when in Cartesian Space, to
have angles, which when summed, come to know more, nor no less, than
nine score degrees, should he so wish.  [TEMPLE OV THEE LEMUR]

Re: Bug in change in button.el?

[Glenn Morris]

Miles Bader wrote:

> Are you sure that you have TERM set correctly (to "linux")?

Yes (though I do sometimes set TERM, so good you made me check).

> Here's what display-supports-face-attributes-p says for the linux console:
>
>    (display-supports-face-attributes-p '(:underline t))
>      => nil
>    (display-supports-face-attributes-p '(:weight bold))
>      => t
>
> If you're using the correct TERM, what do these return for you?

Same as for you, but I don't see bold, either in or out of Emacs. Eg
in man pages, or if I run the good old bash colour script. This is on
RHEL4.4. A quick web search suggests this may be due to RH's choice of
console font (latarcyrheb-sun16 it seems).


#!/bin/bash

esc="\033["

echo -n " _ _ _ _ _40 _ _ _ 41_ _ _ _42 _ _ _ 43"
echo "_ _ _ 44_ _ _ _45 _ _ _ 46_ _ _ _47 _"

for fore in 30 31 32 33 34 35 36 37; do

    line1="$fore  "
    line2="    "

    for back in 40 41 42 43 44 45 46 47; do

        line1="${line1}${esc}${back};${fore}m Normal  ${esc}0m"
        line2="${line2}${esc}${back};${fore};1m Bold    ${esc}0m"

    done

    echo -e "$line1\n$line2"

done

Re: Bug in change in button.el?

[Miles Bader]

Glenn Morris <rgm@gnu.org> writes:
> Same as for you, but I don't see bold, either in or out of Emacs. Eg
> in man pages, or if I run the good old bash colour script. This is on
> RHEL4.4. A quick web search suggests this may be due to RH's choice of
> console font (latarcyrheb-sun16 it seems).

I suppose a bug report to RH is in order...

[Is it a color display?  On the linux console "bold" usually really
means "bright" not actually a different font.]

-Miles

-- 
80% of success is just showing up.  --Woody Allen

Re: Bug in change in button.el?

[Glenn Morris]

Miles Bader wrote:

> I suppose a bug report to RH is in order...

They know. It was in the release notes way back in RH8:

  On the console, the latarcyrheb-sun16 font is used for best Unicode
  coverage. Due to the use of this font, bold colors are not
  available.

> [Is it a color display?  On the linux console "bold" usually really
> means "bright" not actually a different font.]

Yes, it is colour.

I wonder if there is any way for Emacs to tell that bold is not
actually supported in this case? It's not important though.

Re: Bug in change in button.el?

[Miles Bader]

Glenn Morris <rgm@gnu.org> writes:
>   On the console, the latarcyrheb-sun16 font is used for best Unicode
>   coverage. Due to the use of this font, bold colors are not
>   available.
>
>> [Is it a color display?  On the linux console "bold" usually really
>> means "bright" not actually a different font.]
>
> Yes, it is colour.

Do you know why it doesn't support bold via the "usual" linux console
method (using brightness)?  I'd think that would not depend on the font
used.

> I wonder if there is any way for Emacs to tell that bold is not
> actually supported in this case?

Not that I know of.  TERM says bold is supported but it isn't; AFAIK
there's no way to query ansi-type terminals for their capabilities.

-Miles

-- 
"Suppose we've chosen the wrong god. Every time we go to church we're
just making him madder and madder." -- Homer Simpson

Re: Bug in change in button.el?

[Glenn Morris]

Miles Bader wrote:

> Do you know why it doesn't support bold via the "usual" linux console
> method (using brightness)?  I'd think that would not depend on the font
> used.

I know nothing about this stuff.

http://linuxgazette.net/issue91/loozzr.html

says it's because it's a 512 char font, and seems to have lots of
detail that I haven't read.

Re: Bug in change in button.el?

[Andreas Schwab]

Glenn Morris <rgm@gnu.org> writes:

> I wonder if there is any way for Emacs to tell that bold is not
> actually supported in this case? It's not important though.

You have to tell it through the ncv capability (add 32 to it).

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Bug in change in button.el?

[Nick Roberts]

 > I can tell you by experiment that if you make it inherit from
 > underline, it will once again by indistinguishable on the linux
 > console.

Maybe that's because of the odd specification for underline.

 > > No let's sort this case, and leave behaviour otherwise unchanged.
 > 
 > Absolutely!
 > 
 > > RMS can decide which solution to use.
 > 
 > Decide between what choices?

It looks like mine doesn't work.  Let's use yours and that will keep
everyone happy!

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

Re: Bug in change in button.el?

[Miles Bader]

Nick Roberts <nickrob@snap.net.nz> writes:
>  > I can tell you by experiment that if you make it inherit from
>  > underline, it will once again by indistinguishable on the linux
>  > console.
>
> Maybe that's because of the odd specification for underline.

Apparently it's because his console doesn't render bold (which is the
fallback used by the "underline" face if real underlining isn't
supported), despite TERM indicating that it can.

-Miles
-- 
"Unless there are slaves to do the ugly, horrible, uninteresting work, culture
and contemplation become almost impossible. Human slavery is wrong, insecure,
and demoralizing.  On mechanical slavery, on the slavery of the machine, the
future of the world depends." -Oscar Wilde, "The Soul of Man Under Socialism"

Re: Bug in change in button.el?

[Richard Stallman]

      If we want to do this, button might as well
    just inherit from the underline face.

No!  That would change the behavior on some types of terminals, which
is to be avoided!

Re: Bug in change in button.el?

[Richard Stallman]

Please install this patch.

      ;; Use color for the MS-DOS port because it doesn't support underline.
      (defface button '((((type pc) (class color))
		       (:foreground "lightblue"))
    ! 		  (((supports :underline t)) :underline t)
    ! 		  (t (:foreground "lightblue")))
	"Default face used for buttons."

Re: Bug in change in button.el?

[Glenn Morris]

Richard Stallman wrote:

> Please install this patch.

Installed on branch and trunk; item removed from FOR-RELEASE.

Re: Bug in change in button.el?

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Mon, 23 Apr 2007 19:08:10 -0400
> Cc: emacs-devel@gnu.org
> 
>      ;; Use color for the MS-DOS port because it doesn't support underline.
>     -(defface button '((((type pc) (class color))
>     +;; Also for the linux console.
>     +(defface button '((((type pc tty) (class color))
> 
> Doesn't "tty" include xterms?

It does.

Re: Bug in change in button.el?

[Nick Roberts]

Eli Zaretskii writes:
 > > From: Richard Stallman <rms@gnu.org>
 > > Date: Mon, 23 Apr 2007 19:08:10 -0400
 > > Cc: emacs-devel@gnu.org
 > > 
 > >      ;; Use color for the MS-DOS port because it doesn't support underline.
 > >     -(defface button '((((type pc) (class color))
 > >     +;; Also for the linux console.
 > >     +(defface button '((((type pc tty) (class color))
 > > 
 > > Doesn't "tty" include xterms?
 > 
 > It does.

But this change is not in Emacs 22.0.99 or EMACS_22_BASE.

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