Re: [Emacs-diffs] emacs-24 r117559: Fix bug #18636 with documentation of multi-monitor displays.

Re: [Emacs-diffs] emacs-24 r117559: Fix bug #18636 with documentation of multi-monitor displays.

[Glenn Morris]

Eli Zaretskii wrote:

> +Position of the top-left corner and size of the work area in pixels as
> +@samp{(@var{x} @var{y} @var{width} @var{height})}.  This is different
> +from @samp{geometry} in that the various system windows, such as the
> +task bar and side bar, are excluded from the work area.

There were very few previous mentions of "task bar" in Emacs, but all
were written as "taskbar" rather than "task bar". I also think the
details here are likely to be OS-specific. I think "taskbar" is mainly a
MS-Windows term? I never hear it it connection with X, AFAIK; but this
could well be just my ignorance. Eg on X with XFCE, the equivalent would
be "panels", I guess, and these have zero affect: geometry == workarea.

"side bar" was never mentioned before now.

I would suggest maybe rewording this to be less definitive, and
basically just say that the precise details are likely to be
OS-specific.

> +    (workarea 0 0 1920 1050)   ;; Bottom of screen used for task bar

> +	     form of (X Y WIDTH HEIGHT); this excludes task bar etc.

Re: [Emacs-diffs] emacs-24 r117559: Fix bug #18636 with documentation of multi-monitor displays.

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 08 Oct 2014 15:52:31 -0400
> 
> Eli Zaretskii wrote:
> 
> > +Position of the top-left corner and size of the work area in pixels as
> > +@samp{(@var{x} @var{y} @var{width} @var{height})}.  This is different
> > +from @samp{geometry} in that the various system windows, such as the
> > +task bar and side bar, are excluded from the work area.
> 
> There were very few previous mentions of "task bar" in Emacs, but all
> were written as "taskbar" rather than "task bar".

AFAIK, "taskbar" is a non-word.  In any case, these are terms from
outside world that users are well familiar with, so we don't need to
worry how much we use them in our manuals or how exactly we spell
them.

> I also think the details here are likely to be OS-specific. I think
> "taskbar" is mainly a MS-Windows term?

I don't think so (AFAIR, KDE at least uses that term as well), but
feel free to add whatever other terms are used for that thing.

> Eg on X with XFCE, the equivalent would be "panels", I guess, and
> these have zero affect: geometry == workarea.

There's nothing in what I wrote that contradicts the possibility that
workarea geometry is identical to the whole screen.  In fact, on any
monitor but the primary one, this is always the case, at least on
Windows.

> "side bar" was never mentioned before now.

It's popular terminology, not something specific to Emacs.

> I would suggest maybe rewording this to be less definitive, and
> basically just say that the precise details are likely to be
> OS-specific.

I found it very hard to be OS-agnostic here and still convey the
ideas.  The whole issue is obscure (the fact that not many systems
have more than one monitor doesn't help), and its previous description
was more confusing than enlightening.  Feel free to improve, of
course, but I rather think we should add terminology from other
platforms, not remove what's already there, as doing the latter will
make it obscure again.

Re: [Emacs-diffs] emacs-24 r117559: Fix bug #18636 with documentation of multi-monitor displays.

[Stefan Monnier]

>> "side bar" was never mentioned before now.
> It's popular terminology, not something specific to Emacs.

FWIW, like Glenn, I don't know exactly what are taskbars and sidebars.
I vaguely know they're thingies that I've heard mentioned, especially in
a Windows context.

> I found it very hard to be OS-agnostic here and still convey the ideas.

Agreed.

I think replacing "the task bar and side bar" with "task bars and side
bars" is about as good as we can make it.
Better not add terminologu such as "panels" (used also in XFCE), since
these have a fairly strong but different meaning in other systems and
will just lead to more confusion.


        Stefan

Re: [Emacs-diffs] emacs-24 r117559: Fix bug #18636 with documentation of multi-monitor displays.

[Jan Djärv]

Hi.

8 okt 2014 kl. 23:31 skrev Stefan Monnier <monnier@iro.umontreal.ca>:

>>> "side bar" was never mentioned before now.
>> It's popular terminology, not something specific to Emacs.
> 
> FWIW, like Glenn, I don't know exactly what are taskbars and sidebars.
> I vaguely know they're thingies that I've heard mentioned, especially in
> a Windows context.
> 
>> I found it very hard to be OS-agnostic here and still convey the ideas.
> 
> Agreed.
> 
> I think replacing "the task bar and side bar" with "task bars and side
> bars" is about as good as we can make it.
> Better not add terminologu such as "panels" (used also in XFCE), since
> these have a fairly strong but different meaning in other systems and
> will just lead to more confusion.

Gnome uses taskbar and panel: "TaskBar displays icons of running applications on the top panel or alternatively on a new bottom panel."  It seems taskbar is a specialized panel, in that case "panel" would be appripriate.  I think we need some words describing whatever term gets used.

Sidebar is new to me, a panel on the side?

	Jan D.

Re: [Emacs-diffs] emacs-24 r117559: Fix bug #18636 with documentation of multi-monitor displays.

[Eli Zaretskii]

> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Thu, 9 Oct 2014 07:37:34 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>,
>  emacs-devel@gnu.org
> 
> Sidebar is new to me, a panel on the side?

Yes, see http://en.wikipedia.org/wiki/Sidebar_(computing).

Re: [Emacs-diffs] emacs-24 r117559: Fix bug #18636 with documentation of multi-monitor displays.

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Glenn Morris <rgm@gnu.org>,  emacs-devel@gnu.org
> Date: Wed, 08 Oct 2014 17:31:41 -0400
> 
> >> "side bar" was never mentioned before now.
> > It's popular terminology, not something specific to Emacs.
> 
> FWIW, like Glenn, I don't know exactly what are taskbars and sidebars.
> I vaguely know they're thingies that I've heard mentioned, especially in
> a Windows context.
> 
> > I found it very hard to be OS-agnostic here and still convey the ideas.
> 
> Agreed.
> 
> I think replacing "the task bar and side bar" with "task bars and side
> bars" is about as good as we can make it.
> Better not add terminologu such as "panels" (used also in XFCE), since
> these have a fairly strong but different meaning in other systems and
> will just lead to more confusion.

Well, Glenn removed "side bars", which I think is a mistake, but I'm
not going to argue.

Btw, Glenn: you also removed @smallisp -- did you make sure that with
@lisp the example doesn't overflow the right margin in the printed
version of the manual?  That was the reason I used @smallisp: some of
the lines were too long.

Re: [Emacs-diffs] emacs-24 r117559: Fix bug #18636 with documentation of multi-monitor displays.

[Glenn Morris]

Eli Zaretskii wrote:

> @lisp the example doesn't overflow the right margin in the printed
> version of the manual? 

Yes (but as always it depends what paper-size you use).
BTW, in emacs+lispref, @example wins over @lisp in the ratio 50:1.

Re: [Emacs-diffs] emacs-24 r117559: Fix bug #18636 with documentation of multi-monitor displays.

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  emacs-devel@gnu.org
> Date: Thu, 09 Oct 2014 11:56:23 -0400
> 
> BTW, in emacs+lispref, @example wins over @lisp in the ratio 50:1.

Evidently, many people don't even know that @lisp exists.

Re: [Emacs-diffs] emacs-24 r117559: Fix bug #18636 with documentation of multi-monitor displays.

[Glenn Morris]

Eli Zaretskii wrote:

>> BTW, in emacs+lispref, @example wins over @lisp in the ratio 50:1.
>
> Evidently, many people don't even know that @lisp exists.

It seems pointless to me. Quoth the texinfo manual:

    This is useful, for example, if you write a function that evaluates
    only and all the Lisp code in a Texinfo file. Then you can use the
    Texinfo file as a Lisp library.

This example cannot be evaluated as lisp.

Re: [Emacs-diffs] emacs-24 r117559: Fix bug #18636 with documentation of multi-monitor displays.

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Thu, 09 Oct 2014 13:45:43 -0400
> 
> Eli Zaretskii wrote:
> 
> >> BTW, in emacs+lispref, @example wins over @lisp in the ratio 50:1.
> >
> > Evidently, many people don't even know that @lisp exists.
> 
> It seems pointless to me. Quoth the texinfo manual:
> 
>     This is useful, for example, if you write a function that evaluates
>     only and all the Lisp code in a Texinfo file. Then you can use the
>     Texinfo file as a Lisp library.
> 
> This example cannot be evaluated as lisp.

Selective citation alert!  Here's the full one, with key parts
highlighted:

  The '@lisp' command is used for Lisp code.  It is synonymous with the
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  '@example' command.

       This is an example of text written between an
       @lisp command and an @end lisp command.

    Use '@lisp' instead of '@example' to preserve information regarding
  the nature of the example.          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  ^^^^^^^^^^^^^^^^^^^^^^^^^
                              This is useful, for example, if you write a
                                              ^^^^^^^^^^^
  function that evaluates only and all the Lisp code in a Texinfo file.
  Then you can use the Texinfo file as a Lisp library.(1)

Re: [Emacs-diffs] emacs-24 r117559: Fix bug #18636 with documentation of multi-monitor displays.

[Glenn Morris]

It also says:

  It would be straightforward to extend Texinfo to work in a
  similar fashion for C, Fortran, or other languages.

(All the cool, hip languages!)

The fact that no-one ever bothered, and that @lisp is used a grand total
of 16 times in the Emacs Lisp Reference manual, indicates to me that
this feature is... pointless. But YMMV.

Re: [Emacs-diffs] emacs-24 r117559: Fix bug #18636 with documentation of multi-monitor displays.

[David Kastrup]

[-- Attachment #1: Type: text/plain, Size: 1312 bytes --]

Glenn Morris <rgm@gnu.org> writes:

> It also says:
>
>   It would be straightforward to extend Texinfo to work in a
>   similar fashion for C, Fortran, or other languages.
>
> (All the cool, hip languages!)
>
> The fact that no-one ever bothered, and that @lisp is used a grand total
> of 16 times in the Emacs Lisp Reference manual, indicates to me that
> this feature is... pointless. But YMMV.

dak@lola:/usr/local/tmp/lilypond$ git grep '@lilypond' Documentation|wc -l
9097

And indeed, the @lilypond passages are extracted and compiled separately
as LilyPond code, then the images are reinserted into the output.

With an input like

    @node String number indications
    @unnumberedsubsubsec String number indications

    @cindex string numbers
    @cindex string vs. fingering numbers
    @cindex fingering vs. string numbers

    The string on which a note should be played may be indicated by
    appending @code{\@var{number}} to a note.

    @lilypond[verbatim,quote,relative=0]
    \clef "treble_8"
    c4\5 e\4 g2\3
    <c,\5 e\4 g\3>1
    @end lilypond

    When fingerings and string indications are used together, their
    placement can be controlled by the order in which the two items appear
    in the code @emph{only} if they appear inside of an explicit chord:

generating output like


[-- Attachment #2: inf.png --]
[-- Type: image/png, Size: 33119 bytes --]

[-- Attachment #3: Type: text/plain, Size: 281 bytes --]


or the web page

<URL:http://lilypond.org/doc/v2.19/Documentation/notation/common-notation-for-fretted-strings#string-number-indications>

So while the idea might not have caught on in general, in LilyPond's
documentation it is used several thousands of times.

-- 
David Kastrup

Re: [Emacs-diffs] emacs-24 r117559: Fix bug #18636 with documentation of multi-monitor displays.

[Stefan Monnier]

> dak@lola:/usr/local/tmp/lilypond$ git grep '@lilypond' Documentation|wc -l
> 9097

But @lilypond is not a predefined command in Texinfo, right?
I think @lisp should work in the same way (i.e. not be predefined).
But that's not an Emacs problem, anyway.


        Stefan

Re: [Emacs-diffs] emacs-24 r117559: Fix bug #18636 with documentation of multi-monitor displays.

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> dak@lola:/usr/local/tmp/lilypond$ git grep '@lilypond' Documentation|wc -l
>> 9097
>
> But @lilypond is not a predefined command in Texinfo, right?

Correct.  Those environments are mechanically extracted.  Which is a
good thing when you compare it with the @example environment since
LilyPond is an input language containing a _lot_ of { ... } characters.
In @example as opposed to @lilypond, you need to quote them as
@{ ... @}.

-- 
David Kastrup

Re: [Emacs-diffs] emacs-24 r117559: Fix bug #18636 with documentation of multi-monitor displays.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

It might be good to create a Texinfo command that is like @example
but treats braces as ordinary characters.
Lilypond could define @lilypond an alias for that command.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: [Emacs-diffs] emacs-24 r117559: Fix bug #18636 with documentation of multi-monitor displays.

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> It might be good to create a Texinfo command that is like @example
> but treats braces as ordinary characters.

@verbatim is more or less like that, or at least you can combine it with
@quote.  Due to its implementation in TeX, it cannot really be used as a
building block for macros you define yourself.  It's only useful as a
direct user input command.

> Lilypond could define @lilypond an alias for that command.

Since lilypond-book (the application converting files with @lilypond
commands in them into proper Texinfo input) needs to insert the @image
commands pointing to the graphics from processing the content in the
@lilypond command into the actually generated Texinfo input, Texinfo
does not get to see the original environment anyway.

The actually generated input already uses @verbatim and looks something
like

@exampleindent 0
@verbatim
bass = {
  \clef bass
  g4 b, c d
  e d8 c d2
}

continuo = \figuremode {
  <_>4 <6>4 <5/>4
  \override Staff.BassFigureAlignmentPositioning.direction = #UP
  %\bassFigureStaffAlignmentUp
  < _+ >4 <6>
  \set Staff.useBassFigureExtenders = ##t
  \override Staff.BassFigureAlignmentPositioning.direction = #DOWN
  %\bassFigureStaffAlignmentDown
  <4>4. <4>8 <_+>4
}

\score {
  <<
    \new Staff = bassStaff \bass
    \context Staff = bassStaff \continuo
  >>
}
@end verbatim
@noindent
@ifinfo
@image{34/lily-fdcff975,,,[image of music],}
@end ifinfo
@html
<p>
 <a href="34/lily-fdcff975.ly">
  <img align="middle"
       border="0"
       src="34/lily-fdcff975.png"
       alt="[image of music]">
 </a>
</p>
@end html

@iftex
@include 34/lily-fdcff975-systems.texi
@end iftex



Richard, if you treat every example of a working system that somebody
brings up in the course of a discussion as a request for letting you
redesign stuff that has been working for decades to the satisfaction of
its users rather than as input to the discussion, the discussion can go
nowhere.

It's fine to explore possible fundamental deficiencies and its effects
on system and users concerning the aspects under discussion, but when
some particular tangent has veered off completely from the topic of
discussion and the list, it would make sense to continue it, if at all,
in private communication.

-- 
David Kastrup

RE: [Emacs-diffs] emacs-24 r117559: Fix bug #18636 with documentation of multi-monitor displays.

[Drew Adams]

> -----Original Message-----
> From: emacs-devel-bounces+drew.adams=oracle.com@gnu.org
> [mailto:emacs-devel-bounces+drew.adams=oracle.com@gnu.org] On Behalf
> Of Eli Zaretskii
> Sent: Wednesday, October 08, 2014 1:04 PM
> To: Glenn Morris
> Cc: emacs-devel@gnu.org
> Subject: Re: [Emacs-diffs] emacs-24 r117559: Fix bug #18636 with
> documentation of multi-monitor displays.
> 
> > From: Glenn Morris <rgm@gnu.org>
> > Cc: emacs-devel@gnu.org
> > Date: Wed, 08 Oct 2014 15:52:31 -0400
> >
> > Eli Zaretskii wrote:
> >
> > > +Position of the top-left corner and size of the work area in
> pixels as
> > > +@samp{(@var{x} @var{y} @var{width} @var{height})}.  This is
> different
> > > +from @samp{geometry} in that the various system windows, such
> as the
> > > +task bar and side bar, are excluded from the work area.
> >
> > There were very few previous mentions of "task bar" in Emacs, but
> all
> > were written as "taskbar" rather than "task bar".
> 
> AFAIK, "taskbar" is a non-word.  In any case, these are terms from
> outside world that users are well familiar with, so we don't need to
> worry how much we use them in our manuals or how exactly we spell
> them.
> 
> > I also think the details here are likely to be OS-specific. I
> think
> > "taskbar" is mainly a MS-Windows term?
> 
> I don't think so (AFAIR, KDE at least uses that term as well), but
> feel free to add whatever other terms are used for that thing.
> 
> > Eg on X with XFCE, the equivalent would be "panels", I guess, and
> > these have zero affect: geometry == workarea.
> 
> There's nothing in what I wrote that contradicts the possibility
> that
> workarea geometry is identical to the whole screen.  In fact, on any
> monitor but the primary one, this is always the case, at least on
> Windows.
> 
> > "side bar" was never mentioned before now.
> 
> It's popular terminology, not something specific to Emacs.
> 
> > I would suggest maybe rewording this to be less definitive, and
> > basically just say that the precise details are likely to be
> > OS-specific.
> 
> I found it very hard to be OS-agnostic here and still convey the
> ideas.  The whole issue is obscure (the fact that not many systems
> have more than one monitor doesn't help), and its previous
> description
> was more confusing than enlightening.  Feel free to improve, of
> course, but I rather think we should add terminology from other
> platforms, not remove what's already there, as doing the latter will
> make it obscure again.

BTW, what is the reason for the order we have among the `geometry'
and `workarea' components?  Why not use the same order as for the
X Window `geometry' spec?

X Window `geometry': -geometry WIDTHxHEIGHT+XOFF+YOFF
Emacs `geometry': X Y WIDTH HEIGHT

I presume that the component values are the same for Emacs as for
the X Window spec (are they exactly the same things?), but we
start with X(OFF) and Y(OFF) instead of WIDTH and HEIGHT.