Reveal mode

Reveal mode

[Richard Stallman]

Do people think that Reveal mode should be enabled by default?

Re: Reveal mode

[Pavel Janík]

   From: Richard Stallman <rms@gnu.org>
   Date: Tue, 30 Apr 2002 15:19:10 -0600 (MDT)

   > Do people think that Reveal mode should be enabled by default?

I think it can be confusing. I found it really useful and instead of
enabling it by default, I'd prefer to have it documented in the manual so
users can easily enable it.
-- 
Pavel Janík

Test input for validity and plausibility.
                  --  The Elements of Programming Style (Kernighan & Plaugher)

Enhancements to options menu (was Re: Reveal mode)

[Kim F. Storm]

Pavel@Janik.cz (Pavel Janík) writes:

>    From: Richard Stallman <rms@gnu.org>
>    Date: Tue, 30 Apr 2002 15:19:10 -0600 (MDT)
> 
>    > Do people think that Reveal mode should be enabled by default?
> 
> I think it can be confusing. I found it really useful and instead of
> enabling it by default, I'd prefer to have it documented in the manual so
> users can easily enable it.

I think that we should consider adding a few more sub-menues
to the Options menu to make more of the built-in functionality
of emacs directly selectable:

        More Display Options   ->

                Reveal Mode
                Show Trailing Whitespace
                Blinking Cursor
                Display Image Files
                Glasses mode
                Highlight current line
                Resize Minibuffer Mode

        More Editing Options   ->

                Auto-Expand Abbreviations
                Auto-Revert files (when changed outside emacs)
                Auto-Save files
                C warning Mode
                Refill Mode
                Write using mouse (Strokes mode)

        More Environment Options   ->

                Interactive Buffer Switching
                Incremental completion mode
                Mouse avoidance mode  ->  [option list]
                Mouse wheel support
                CUA mode
                VIPER mode
                Delete Selection mode
                PC selection mode
                Remember Recently Edited files
                Undoable window changes (winner mode)

Also on Show/Hide, add

                Battery indicator
                Ruler
                Current function name (Which Function mode)


On the edit menu, add

                Overwrite Mode
                Artist Mode
                Picture Mode

Re: Enhancements to options menu

[Karl Eichwalder]

storm@cua.dk (Kim F. Storm) writes:

> I think that we should consider adding a few more sub-menues
> to the Options menu

Doing configuration through (sub)menus is quite cumbersome.  State of
the art is to offer some major setting through menu toggle line ("Enable
Javascript" in galeon) and offer the rest through "Preferences..."
dialog screens (a "notebook" or "tabs").

Often less is more :)

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.suse.de/~ke/                                  |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

Re: Enhancements to options menu

[Per Abrahamsen]

Karl Eichwalder <ke@gnu.franken.de> writes:

> Doing configuration through (sub)menus is quite cumbersome.  State of
> the art is to offer some major setting through menu toggle line ("Enable
> Javascript" in galeon) and offer the rest through "Preferences..."
> dialog screens (a "notebook" or "tabs").

Would a subset of the M-x customize-browse <ret> tree do the trick?

Re: Enhancements to options menu

[Kim F. Storm]

Karl Eichwalder <ke@gnu.franken.de> writes:

> storm@cua.dk (Kim F. Storm) writes:
> 
> > I think that we should consider adding a few more sub-menues
> > to the Options menu
> 
> Doing configuration through (sub)menus is quite cumbersome. 

Yes, but it allows us to easily demonstrate the available features
without adding the complexity of a large "Preferences" buffer with
lots of buttons...

> State of
> the art is to offer some major setting through menu toggle line ("Enable
> Javascript" in galeon) and offer the rest through "Preferences..."
> dialog screens (a "notebook" or "tabs").
> 
> Often less is more :)
>

But today we have very few easily accessible options -- and to find
the rest is pretty difficult for the novice users.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Enhancements to options menu

[Karl Eichwalder]

storm@cua.dk (Kim F. Storm) writes:

> But today we have very few easily accessible options -- and to find
> the rest is pretty difficult for the novice users.

I disagree.  "Options" already holds 11 toggle buttons + 3 entries
opening sub panes + the Save button.

Why is customize difficult to find?  Maybe, "Customize Emacs" should
come as the first entry in "Options"?  Maybe, a better label would be
"Customize Emacs (Preferences)"?

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.suse.de/~ke/                                  |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

Re: Enhancements to options menu (was Re: Reveal mode)

[Richard Stallman]

    I think that we should consider adding a few more sub-menues
    to the Options menu to make more of the built-in functionality
    of emacs directly selectable:

I am strongly against that, because it embarks on a path of
duplicating the Custom facilities, one option at a time.  We should
encourage users to use that facility instead.  If it is not good
enough, we should improve it.

Re: Enhancements to options menu (was Re: Reveal mode)

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     I think that we should consider adding a few more sub-menues
>     to the Options menu to make more of the built-in functionality
>     of emacs directly selectable:
> 
> I am strongly against that, because it embarks on a path of
> duplicating the Custom facilities, one option at a time. 

That's ok.  However, for new users, I would like to have something a
little less overwhelming (and easier to browse) than the full-blown
customize interface.

>  We should
> encourage users to use that facility instead.  If it is not good
> enough, we should improve it.

Maybe we could create a "preferences" page which contains toggles for,
say, 25 commonly used options, and also a link to the customize group
for that option.  That would allow novice users to quickly get to
some of the more advanced options of emacs.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Enhancements to options menu (was Re: Reveal mode)

[Thien-Thi Nguyen]

storm@cua.dk (Kim F. Storm) writes:

   Maybe we could create a "preferences" page which contains toggles
   for, say, 25 commonly used options, and also a link to the customize
   group for that option.  That would allow novice users to quickly get
   to some of the more advanced options of emacs.

here's another idea: w/ support from a "graphical expect" framework and
some magicpoint generation macros, someone could write a demo (in elisp)
and link it to the customize (or other) preference-setting interfaces.

i imagine arrows dancing around the screen, some question like "these
are fringes -- do you belong to the minimalist school of thought; i.e.,
would you prefer to remove them?", a small button "no", and a HUGE
button "yes please oh yes what were the emacs hackers thinking?!"....

(ok, it's probably evident user interface design is not my forte. ;-)

thi

Re: Enhancements to options menu (was Re: Reveal mode)

[Pavel Janík]

   From: Thien-Thi Nguyen <ttn@glug.org>
   Date: 03 May 2002 20:39:35 -0400

   > i imagine arrows dancing around the screen, some question like "these
   > are fringes -- do you belong to the minimalist school of thought; i.e.,

I think that we miss a chapter with this in the manual...
-- 
Pavel Janík

Use the fundamental control flow constructs.
                  --  The Elements of Programming Style (Kernighan & Plaugher)

Re: Enhancements to options menu (was Re: Reveal mode)

[Alex Schroeder]

storm@cua.dk (Kim F. Storm) writes:

> Maybe we could create a "preferences" page which contains toggles for,
> say, 25 commonly used options, and also a link to the customize group
> for that option.  That would allow novice users to quickly get to
> some of the more advanced options of emacs.

To collect a subset of existing options in a new group is trivial,
somebody just has to decide upon the 25 options, and somebody else
(me, for example) could write the code in a few minutes.  All I need
is the name of this new group, and the list of existing options you
want.

This works by using the MEMBERS argument to defgroup.

Alex.
-- 
http://www.electronicintifada.net/diaries/index.html
http://www.us-israel.org/jsource/US-Israel/hr2506c.html

Re: Enhancements to options menu (was Re: Reveal mode)

[Richard Stallman]

    That's ok.  However, for new users, I would like to have something a
    little less overwhelming (and easier to browse) than the full-blown
    customize interface.

Why do you think it is "overwhelming"?  What makes it difficult to
browse?  Perhaps Custom can be improved, but if we want to have any chance
to improve it, we need to think more concretely.

If we want to make a drastic change, we should use the existing Custom
data structure and build another interface to use it.

    >  We should
    > encourage users to use that facility instead.  If it is not good
    > enough, we should improve it.

    Maybe we could create a "preferences" page which contains toggles for,
    say, 25 commonly used options, and also a link to the customize group
    for that option.

I don't understand this proposal.  For instance, you speak of a
"page"; what does that mean here?  Could you use the standard term
for whatever entity you have in mind?

The only "pages" in Emacs are the ones that C-x C-p handles.

Re: Enhancements to options menu (was Re: Reveal mode)

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     That's ok.  However, for new users, I would like to have something a
>     little less overwhelming (and easier to browse) than the full-blown
>     customize interface.
> 
> Why do you think it is "overwhelming"?  What makes it difficult to
> browse?  Perhaps Custom can be improved, but if we want to have any chance
> to improve it, we need to think more concretely.

IMO, the custom interface is overwhelming in the sense that it doesn't
really prioritize the options.  As a new user, I would like to see a buffer
with a few checkboxes enabling and disabling major features like:

        [x] Abbreviation mode    [advanced]
        [x] Revert mode          [advanced]

etc  (see my original mail for more examples)...

As a user gets more advanced, he can venture into fine-tuning the various
packages using the customize interface (e.g using the [advanced] button).

> 
> If we want to make a drastic change, we should use the existing Custom
> data structure and build another interface to use it.
> 
>     >  We should
>     > encourage users to use that facility instead.  If it is not good
>     > enough, we should improve it.
> 
>     Maybe we could create a "preferences" page which contains toggles for,
>     say, 25 commonly used options, and also a link to the customize group
>     for that option.
> 
> I don't understand this proposal.  For instance, you speak of a
> "page"; what does that mean here?  Could you use the standard term
> for whatever entity you have in mind?

Sorry, I meant "buffer".

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Enhancements to options menu (was Re: Reveal mode)

[Richard Stallman]

    IMO, the custom interface is overwhelming in the sense that it doesn't
    really prioritize the options.

So, if we had a command to customize a selected list of the 50 most
important options, using the existing Custom facility, would that
do the job?

Another idea: it would also be possible to sort the options in any
given Custom buffer, if we assigned them importance levels.
The more important options could come first.

Another idea: the Custom buffer could show the important options for
any given topic, and end with a button Show Less-Important Options
with which you could see the rest of the options for that topic.
Perhaps we could do that whenever the number of options exceeds a
certain threshold.

I don't entirely understand this suggestion:

        [x] Abbreviation mode    [advanced]
        [x] Revert mode          [advanced]

What does "advanced" mean here?

Re: Enhancements to options menu (was Re: Reveal mode)

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     IMO, the custom interface is overwhelming in the sense that it doesn't
>     really prioritize the options.
> 
> So, if we had a command to customize a selected list of the 50 most
> important options, using the existing Custom facility, would that
> do the job?

At least, that would be a step in the right direction....

I want a "novice" level of customization where a new emacs user can
quickly get an overview of the various features offered by emacs -
preferably just with one option per package ... and preferably 
not more complex than it can be shown in a single 24x80 window.

> 
> Another idea: it would also be possible to sort the options in any
> given Custom buffer, if we assigned them importance levels.
> The more important options could come first.

Agree.

But I think options are shown in the sequence in which they occur
in the source files.... so it is just a question of ordering them
there  (maybe adding a few :set-after properties).

> 
> Another idea: the Custom buffer could show the important options for
> any given topic, and end with a button Show Less-Important Options
> with which you could see the rest of the options for that topic.
> Perhaps we could do that whenever the number of options exceeds a
> certain threshold.

I don't think this is necessary...
If options are shown in order of decreasing importance,
I guess the user can just avoid using "page down"...

> 
> I don't entirely understand this suggestion:
> 
>         [x] Abbreviation mode    [advanced]
>         [x] Revert mode          [advanced]
> 
> What does "advanced" mean here?
> 
> 

It would enter the corresponding custiomize-group.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Enhancements to options menu (was Re: Reveal mode)

[Stefan Monnier]

>    From: Thien-Thi Nguyen <ttn@glug.org>
>    Date: 03 May 2002 20:39:35 -0400
> 
>    > i imagine arrows dancing around the screen, some question like "these
>    > are fringes -- do you belong to the minimalist school of thought; i.e.,
> 
> I think that we miss a chapter with this in the manual...

If you're talking about the dancing arrows, I might agree, although
I'd point out that we also miss the corresponding implementation.
As for the fringes, I would rather not advertise the ability to
remove them (to new users).  I didn't like them at first, but I now
think they're really cool (the only thing missing is the "cursor
inside the right fringe" feature which would allow us to display 80
char lines with no wrapping).
I think new users could be tempted to turn them off and never discover
how cool they are (and/or whine about how lame the gdb-arrow looks).


	Stefan

Re: Enhancements to options menu (was Re: Reveal mode)

[Eli Zaretskii]

On 6 May 2002 storm@cua.dk wrote:

> I want a "novice" level of customization where a new emacs user can
> quickly get an overview of the various features offered by emacs -
> preferably just with one option per package ... and preferably 
> not more complex than it can be shown in a single 24x80 window.

I think you are talking about two different features.  One is what _I_ 
call a ``novice'' customization level: a command that lets the user 
customize a relatively short list of the most popular options.  If the 
decision is that we don't want to put them on menu-bar's Options, then 
some variety of Customize is the logical alternative.

The other feature is some way of getting a summary of the optional 
features and being able to browse them.  That sounds a lot like top-level 
Customize groups, perhaps flattened to some extent, doesn't it?  The one 
option per package goal seems an impossible one--just pick up any Emacs 
package and try to decide what would be that single option you will 
show.  I'm unable to do that, FWIW: too many are useful.

Re: Enhancements to options menu (was Re: Reveal mode)

[Miles Bader]

Eli Zaretskii <eliz@is.elta.co.il> writes:
> The one option per package goal seems an impossible one--just pick up
> any Emacs package and try to decide what would be that single option
> you will show.  I'm unable to do that, FWIW: too many are useful.

That's true in general, but for packages which can be `enabled or
disabled' (e.g. global minor modes), this would be a very good way to
present them.

That's how I interpreted Kim's suggestion -- the `short list' would
allow one to enable or disable various features, and the [advanced]
button would jump to the ordinary custom page where one could change the
details of how the feature works.

-Miles
-- 
Come now, if we were really planning to harm you, would we be waiting here, 
 beside the path, in the very darkest part of the forest?

Re: Enhancements to options menu (was Re: Reveal mode)

[Kim F. Storm]

Miles Bader <miles@gnu.org> writes:

> Eli Zaretskii <eliz@is.elta.co.il> writes:
> > The one option per package goal seems an impossible one--just pick up
> > any Emacs package and try to decide what would be that single option
> > you will show.  I'm unable to do that, FWIW: too many are useful.
> 
> That's true in general, but for packages which can be `enabled or
> disabled' (e.g. global minor modes), this would be a very good way to
> present them.
> 
> That's how I interpreted Kim's suggestion -- the `short list' would
> allow one to enable or disable various features, and the [advanced]
> button would jump to the ordinary custom page where one could change the
> details of how the feature works.

Exactly.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Enhancements to options menu (was Re: Reveal mode)

[Richard Stallman]

    > Another idea: it would also be possible to sort the options in any
    > given Custom buffer, if we assigned them importance levels.
    > The more important options could come first.

    Agree.

    But I think options are shown in the sequence in which they occur
    in the source files.... so it is just a question of ordering them
    there  (maybe adding a few :set-after properties).

Would someone like to start attacking various packages
and adjusting the order of options to be the best possible
for the users?

If you occasionally pick one file and do this, over time
the situation will get better.

Re: Enhancements to options menu (was Re: Reveal mode)

[Richard Stallman]

    > I don't entirely understand this suggestion:
    > 
    >         [x] Abbreviation mode    [advanced]
    >         [x] Revert mode          [advanced]
    > 
    > What does "advanced" mean here?
    > 
    > 

    It would enter the corresponding custiomize-group.

How is that different from what M-x customize-browse does?

Re: Enhancements to options menu (was Re: Reveal mode)

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     > I don't entirely understand this suggestion:
>     > 
>     >         [x] Abbreviation mode    [advanced]
>     >         [x] Revert mode          [advanced]
>     > 
>     > What does "advanced" mean here?
>     > 
>     > 
> 
>     It would enter the corresponding custiomize-group.
> 
> How is that different from what M-x customize-browse does?

Try this "dummy" preferences code to see what I'm suggesting:

(require 'wid-edit)
(require 'cus-edit)

(defun preferences ()
  "Create a buffer containing popular customization options."
  (interactive)
  (let ((name "*Preferences*"))
    (kill-buffer (get-buffer-create name))
    (pop-to-buffer (get-buffer-create name))
    (custom-mode)
    (buffer-disable-undo)

    (widget-insert "Display Options\n\n")

    (widget-create 'checkbox)
    (widget-insert " Auto Reveal hidden text\t")
    (widget-create 'push-button :tag "Advanced")
    (widget-insert "\n")

    (widget-create 'checkbox)
    (widget-insert " Show trailing Whitespace\t")
    (widget-create 'push-button :tag "Advanced")
    (widget-insert "\n")

    (widget-create 'checkbox)
    (widget-insert " Indicate Empty Lines\t\t")
    (widget-create 'push-button :tag "Advanced")
    (widget-insert "\n")

    (widget-create 'checkbox)
    (widget-insert " Display Image files\t\t")
    (widget-create 'push-button :tag "Advanced")
    (widget-insert "\n")

    (widget-create 'checkbox)
    (widget-insert " Highlight current line\t")
    (widget-create 'push-button :tag "Advanced")
    (widget-insert "\n")

    (widget-create 'checkbox)
    (widget-insert " Blinking cursor\t\t")
    (widget-create 'push-button :tag "Advanced")
    (widget-insert "\n")

    (widget-create 'checkbox)
    (widget-insert " Auto resize minibuffer\t")
    (widget-create 'push-button :tag "Advanced")
    (widget-insert "\n")

    (widget-insert "\nEditing Options\n\n")

    (widget-create 'checkbox)
    (widget-insert " Auto Expand Abbreviations\t")
    (widget-create 'push-button :tag "Advanced")
    (widget-insert "\n")

    (widget-create 'checkbox)
    (widget-insert " Auto Revert changed files\t")
    (widget-create 'push-button :tag "Advanced")
    (widget-insert "\n")

    (widget-create 'checkbox)
    (widget-insert " Auto Save files\t\t")
    (widget-create 'push-button :tag "Advanced")
    (widget-insert "\n")

    (widget-create 'checkbox)
    (widget-insert " Auto Expand Abbreviations\t")
    (widget-create 'push-button :tag "Advanced")
    (widget-insert "\n\n")

    (widget-insert "         ")
    (widget-create 'push-button
		   :tag "Save"
		   :help-echo "\
Make your editing in this buffer take effect for future Emacs sessions."
		   :action (lambda (widget &optional event)
			     (Custom-save)))
    (widget-insert "   ")
    (widget-create 'push-button
		   :tag "Cancel"
		   :help-echo
		   (lambda (&rest ignore)
		     (cond
		      ((eq custom-buffer-done-function
			   'custom-bury-buffer)
		       "Bury this buffer")
		      ((eq custom-buffer-done-function 'kill-buffer)
		       "Kill this buffer")
		      (t "Finish with this buffer")))
		   :action #'Custom-buffer-done)
    (widget-insert "\n\n")
    (widget-setup)
    (buffer-enable-undo)
    (goto-char (point-min))))

Re: Enhancements to options menu (was Re: Reveal mode)

[Pavel Janík]

   From: "Stefan Monnier" <monnier+gnu/emacs@RUM.cs.yale.edu>
   Date: Sun, 05 May 2002 19:15:15 -0400

Hi Stefan,

   > >    > i imagine arrows dancing around the screen, some question like "these
   > >    > are fringes -- do you belong to the minimalist school of thought; i.e.,
   > > 
   > > I think that we miss a chapter with this in the manual...
   > 
   > If you're talking about the dancing arrows, I might agree, although
   > I'd point out that we also miss the corresponding implementation.

;-) No, I was not talking about dancing arrows. I often found that many
people find the Emacs terminology confusing. They do read (emacs)Glossary,
(emacs)Screen but they would like to see pictures. One picture is more then
ten pages of text. I have spent one "lesson" with my users to describe them
the difference between mode-line and echo area and window/buffer, you know.

   > As for the fringes, I would rather not advertise the ability to
   > remove them (to new users).

Well, but this was the most asked question just after releasing 21.1... So
users (and even novice users) wanted to remove it.
-- 
Pavel Janík

We are Linux.
Resistance indicates that you're missing the point!
                  -- "Carsten Otte" <COTTE@de.ibm.com> in LKML

Re: Enhancements to options menu (was Re: Reveal mode)

[Simon Josefsson]

Pavel@Janik.cz (Pavel Janík) writes:

>    > >    > i imagine arrows dancing around the screen, some question like "these
>    > >    > are fringes -- do you belong to the minimalist school of thought; i.e.,
>    > > 
>    > > I think that we miss a chapter with this in the manual...
>    > 
>    > If you're talking about the dancing arrows, I might agree, although
>    > I'd point out that we also miss the corresponding implementation.
>
> ;-) No, I was not talking about dancing arrows. I often found that many
> people find the Emacs terminology confusing. They do read (emacs)Glossary,
> (emacs)Screen but they would like to see pictures. One picture is more then
> ten pages of text. I have spent one "lesson" with my users to describe them
> the difference between mode-line and echo area and window/buffer, you know.

Texinfo supports images, but does the Info format?  I agree it would
be very useful if documentation could include screenshots.

Re: Enhancements to options menu (was Re: Reveal mode)

[Eli Zaretskii]

> From: Simon Josefsson <jas@extundo.com>
> Date: Tue, 07 May 2002 18:33:51 +0200
> 
> Texinfo supports images, but does the Info format?

No, it doesn't.

> I agree it would be very useful if documentation could include
> screenshots.

I think Texinfo lacks some crucial means required to document GUI
programs.  There are no directives to describe a sequence of menu
selections, no way to typeset dialog boxes and other simple widgets,
etc.  IMHO, this all should be figured out and added to the language
before we could start doing serious work documenting the GUI stuff.

Re: Enhancements to options menu (was Re: Reveal mode)

[Karl Berry]

    > Texinfo supports images, but does the Info format?

    No, it doesn't.

How can the Info format support images?
If you make an ASCII drawing picture.txt, the @image command will read it.

    There are no directives to describe a sequence of menu selections,

Why not just use arrows?
start -> next -> next -> command

    no way to typeset dialog boxes and other simple widgets,

How can such things be represented in text-based Info?
They're usually screen shots in other formats, which is probably what's
most useful to users.  I'm not sure there's much point in
transliterating fancy gui stuff into text?
Can ghostscript create ascii from .eps?

Re: Enhancements to options menu (was Re: Reveal mode)

[Simon Josefsson]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

>> I agree it would be very useful if documentation could include
>> screenshots.
>
> I think Texinfo lacks some crucial means required to document GUI
> programs.  There are no directives to describe a sequence of menu
> selections, no way to typeset dialog boxes and other simple widgets,
> etc.  IMHO, this all should be figured out and added to the language
> before we could start doing serious work documenting the GUI stuff.

It later occured to me that I don't see a good reason for extended the
Info format with these capabilities -- there is a perfectly fine
format for text with hyperlinks and images called HTML (I hope that
doesn't come as a suprise to anyone) and making a viewer in Emacs for
texi2html converted manuals similar to Info is IMHO a better
solution. Or DocBook?  Hm.

Re: Enhancements to options menu (was Re: Reveal mode)

[Eli Zaretskii]

> Date: Tue, 7 May 2002 14:30:32 -0400
> From: karl@freefriends.org
> 
> How can the Info format support images?

If the Info file is read in Emacs, the image can be displayed.  In the
stand-alone reader, some text could be available instead, perhaps an
ASCII-art equivalent if possible, or a text description if not, just
like with text-mode HTML browers.

> If you make an ASCII drawing picture.txt, the @image command will read it.

Right.  But I think there should be some means of actually displaying
the image if the browser can handle that.

>     There are no directives to describe a sequence of menu selections,
> 
> Why not just use arrows?
> start -> next -> next -> command

It's a possibility, but not the prettiest one, I think.  (I'm thinking
about the printed version, mainly, not about plain-ASCII readers such
as the stand-alone Info.)  Most books I've seen that document GUI
software have special glyphs to typeset this.

>     no way to typeset dialog boxes and other simple widgets,
> 
> How can such things be represented in text-based Info?

Similar to @image, with some ASCII art, I guess.

> They're usually screen shots in other formats, which is probably what's
> most useful to users.  I'm not sure there's much point in
> transliterating fancy gui stuff into text?

Well, we do have @cartouche, for example.  Isn't it possible to
typeset a dialog box with a caption, a few buttons, etc., along the
same lines?

In other words, we don't need to confine ourselves to screen shots
(those are not easy to create to begin with).  The idea is to have
special directives to typeset popular widgets where we nowadays use
verbal descriptions.

Again, I'm thinking primarily about the printed version, not about
what the stand-alone Info will display.  Many books about GUI programs
use something like this, I'm sure you will find many examples in your
favorite bookstore.  (We even talked with you about this some time
ago.)

> Can ghostscript create ascii from .eps?

I don't know.  Anybody?

Re: Enhancements to options menu (was Re: Reveal mode)

[Richard Stallman]

I see three differences from customize-browse:

A. It doesn't have all the custom groups, just some.

B. They are displayed as one flat series, not in a hierarchy.

C. Each line has an enable-disable button at the beginning.

It seems like an idea worth trying.

Re: Enhancements to options menu (was Re: Reveal mode)

[Stefan Monnier]

>    > As for the fringes, I would rather not advertise the ability to
>    > remove them (to new users).
> Well, but this was the most asked question just after releasing 21.1... So
> users (and even novice users) wanted to remove it.

I'm not sure whether those users were novices, but even if they were,
that's not relevant.  My point is that fringes are good and if a novice
removes them because she thinks she doesn't need them, she'll probably
hit problems later on because of it.
We don't break Java's memory safety just because some novice Java
programmers might ask "how do I do pointer arithmetic".


	Stefan

Re: Enhancements to options menu (was Re: Reveal mode)

[Miles Bader]

Simon Josefsson <jas@extundo.com> writes:
> there is a perfectly fine format for text with hyperlinks and images
> called HTML (I hope that doesn't come as a suprise to anyone) and
> making a viewer in Emacs for texi2html converted manuals similar to
> Info is IMHO a better solution.

Supporting HTML would be _much_ more complex than making simple
extensions to info (note that the w3 html rendering code, which has been
worked on for many years, is still very buggy, and almost unusably slow
on many machines).

-Miles
-- 
Quidquid latine dictum sit, altum viditur.

Re: Enhancements to options menu (was Re: Reveal mode)

[Colin Walters]

On Tue, 2002-05-07 at 20:27, Miles Bader wrote:

> Supporting HTML would be _much_ more complex than making simple
> extensions to info (note that the w3 html rendering code, which has been
> worked on for many years, is still very buggy, and almost unusably slow
> on many machines).

Supporting *all* of HTML certainly would be an enormous effort.  But
supporting the simple subset that texi2html generates shouldn't be hard.

Re: Enhancements to options menu (was Re: Reveal mode)

[Stefan Monnier]

> > Supporting HTML would be _much_ more complex than making simple
> > extensions to info (note that the w3 html rendering code, which has been
> > worked on for many years, is still very buggy, and almost unusably slow
> > on many machines).
> 
> Supporting *all* of HTML certainly would be an enormous effort.  But
> supporting the simple subset that texi2html generates shouldn't be hard.

Let me just say that SGML syntax is hairy.
Now, I've said it.


	Stefan "who has worked a bit on sgml-mode.el"

Re: Enhancements to options menu (was Re: Reveal mode)

[Eli Zaretskii]

On Tue, 7 May 2002, Simon Josefsson wrote:

> It later occured to me that I don't see a good reason for extended the
> Info format with these capabilities -- there is a perfectly fine
> format for text with hyperlinks and images called HTML (I hope that
> doesn't come as a suprise to anyone) and making a viewer in Emacs for
> texi2html converted manuals similar to Info is IMHO a better
> solution.

Using HTML is IMHO a much worse solution, since HTML doesn't support 
features like index searches without which a manual cannot be easily
used as a reference.  That is, if you need to quickly find information
about some very specific issue--a command, a key, a subject like "version 
control" or "compilation errors"--with HTML, all you have is text search, 
which is both inefficient and relies on the keywords to be actually
present in the text.

Many advanced Info features, including quite a few Emacs features related 
to documentation, use the Info indices extensively.

In any case, texi2html is not required since makeinfo is capable of 
producing HTML (and even DocBook, as of the latest release 4.2 of 
Texinfo).

Re: Enhancements to options menu (was Re: Reveal mode)

[Thien-Thi Nguyen]

"Stefan Monnier" <monnier+gnu/emacs@RUM.cs.yale.edu> writes:

   I'm not sure whether those users were novices, but even if they were,
   that's not relevant.  My point is that fringes are good and if a
   novice removes them because she thinks she doesn't need them, she'll
   probably hit problems later on because of it.  We don't break Java's
   memory safety just because some novice Java programmers might ask
   "how do I do pointer arithmetic".

hmmm, you make it sound like turning off fringes incurs some kind of
threat to emacs' structural integrity or design, which would shock me if
it were true.  [insert console-freak rantings here.]

in any case, to get back on topic, i suggest looking at the "separate
demo program" approach when it comes to these kinds of "what should be
DEFAULT?" decisions.  emacs now has (more) mature network capabilities,
so might as well go all the way and define a "standard listener protocol
for configuration" to shift these questions to userland, where tastes
are properly fickle and fluid.

this way, even the configuration style can be user-configured (via
guile-gtk frontend, or sawfish, or dotfile generator, etc).  we would no
longer need to sketch a composite user to target, but let users describe
themselves (through their preferred way of expressing themselves).

in the end, the demo is maintained by users for themselves.  its
simplistic modeling of "preference" extends as users learn to program
more, to take advantage of its underlying expect(1)-nature (and API!).
all users participate in programming emacs.

demos can be a fine thing full of art and craft, with cool Change at its
core.  emacs as next p2p virus -- woo hoo!

thi

Re: Enhancements to options menu (was Re: Reveal mode)

[Per Abrahamsen]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> Using HTML is IMHO a much worse solution, since HTML doesn't support 
> features like index searches without which a manual cannot be easily
> used as a reference.  

Is index search a file format feature?  

I'd say that a

  <link rev="INDEX" href="foo-index.html">

in the pages generated by makeinfo should do the trick, together with
an automatic generation of an suitable formatted foo-index.html file.

Re: Enhancements to options menu (was Re: Reveal mode)

[Eli Zaretskii]

On Wed, 8 May 2002, Per Abrahamsen wrote:

> Eli Zaretskii <eliz@is.elta.co.il> writes:
> 
> > Using HTML is IMHO a much worse solution, since HTML doesn't support 
> > features like index searches without which a manual cannot be easily
> > used as a reference.  
> 
> Is index search a file format feature?  

It's mainly a browser feature, I think.

> I'd say that a
> 
>   <link rev="INDEX" href="foo-index.html">
> 
> in the pages generated by makeinfo should do the trick, together with
> an automatic generation of an suitable formatted foo-index.html file.

I don't think I understand, sorry for being dense.  Can you show an 
example of HTML using this, including what should be in foo-index.html,
and also explain how would that make it possible to do something similar 
to the Info command "i foo RET"?

Re: Enhancements to options menu (was Re: Reveal mode)

[Stefan Monnier]

> "Stefan Monnier" <monnier+gnu/emacs@RUM.cs.yale.edu> writes:
> 
>    I'm not sure whether those users were novices, but even if they were,
>    that's not relevant.  My point is that fringes are good and if a
>    novice removes them because she thinks she doesn't need them, she'll
>    probably hit problems later on because of it.  We don't break Java's
>    memory safety just because some novice Java programmers might ask
>    "how do I do pointer arithmetic".
> 
> hmmm, you make it sound like turning off fringes incurs some kind of
> threat to emacs' structural integrity or design, which would shock me if
> it were true.  [insert console-freak rantings here.]

Admittedly, I forced the tone.  But I just feel like users might miss
on the neat fringes just because they think they don't want them.
If you turn off the fringes you lose:
- legibility (chars stuck right next to a window border are more difficult
  to read; the fringes act like a margin).
- continuation glyphs (i.e. it's not the same as on console).
- neat icons instead of overlayed text for the gud&edebug overlay arrow.
- various future extensions like mouse bindings in the fringes.

I don't think the tradeoffs are obvious to the first-time user (even if he's
an experienced Emacs user) so she might make the wrong decision.  This
is to be contrasted to other "similar" things like the menu-bar, the
tool-bar, the scroll-bar where the user can be reasonably expected to know
what she loses by turning it off.

I'm not saying turning off the fringe should be a hidden feature.
Just that it shouldn't be in the user's face.


	Stefan

Re: Enhancements to options menu (was Re: Reveal mode)

[Stefan Monnier]

> > It later occured to me that I don't see a good reason for extended the
> > Info format with these capabilities -- there is a perfectly fine
> > format for text with hyperlinks and images called HTML (I hope that
> > doesn't come as a suprise to anyone) and making a viewer in Emacs for
> > texi2html converted manuals similar to Info is IMHO a better
> > solution.
> 
> Using HTML is IMHO a much worse solution, since HTML doesn't support 
> features like index searches without which a manual cannot be easily
> used as a reference.  That is, if you need to quickly find information

As far as I can tell, there's nothing very specific in the info
format for indices.  There's just a convention that the top node
should have one or more entries with names like "Foo Index" and that
those subnodes should be made up of just one large menu of xrefs.
The same could be done for HTML, I'm sure.

What bothers me more is that HTML seems much less amenable to
regexp-searching than the info format and if we can't use regexp-searching
that means we need to do real parsing and that's going to be *much* slower.
But maybe I'm wrong.  Simon should feel free to try and implement it.


	Stefan

Re: Enhancements to options menu (was Re: Reveal mode)

[Eli Zaretskii]

On Wed, 8 May 2002, Stefan Monnier wrote:

> As far as I can tell, there's nothing very specific in the info
> format for indices.  There's just a convention that the top node
> should have one or more entries with names like "Foo Index" and that
> those subnodes should be made up of just one large menu of xrefs.
> The same could be done for HTML, I'm sure.

"makeinfo --html" already creates the index nodes.

However, to use the indices efficiently (as opposed to just as large 
menus with links), you need the browser to support the equivalent 
of Info-index, Info-index-next, etc.  Otherwise, looking up a subject 
becomes a much more tedious process, especially if the manual has several 
large indices (e.g., the Emacs manual).

Is there any browser that supports such feature?  I'm not aware of such a 
browser.

> What bothers me more is that HTML seems much less amenable to
> regexp-searching than the info format and if we can't use regexp-searching
> that means we need to do real parsing and that's going to be *much* slower.

That, too, makes HTML less useful for reference-style use of a manual.

Re: Enhancements to options menu (was Re: Reveal mode)

[Richard Stallman]

Texinfo supports putting images in the manual, nowadays.
Would someone like to make an image that shows labels for the various
parts of a frame, and we could put that in the manual?

I think Info files support images at present only by converting them
to ASCII art.  So this image won't probably won't appear in a readable
way in Info.  There is no need to let that stop you--just use @iftex.

In the long run, we would like to have a way to use images
in Info files now that Emacs could display them properly.
What's needed first is a representation for the image in the file.

I am not convinced we should abolish Info files for HTML.

Re: Enhancements to options menu (was Re: Reveal mode)

[Kai Großjohann]

Simon Josefsson <jas@extundo.com> writes:

> It later occured to me that I don't see a good reason for extended the
> Info format with these capabilities -- there is a perfectly fine
> format for text with hyperlinks and images called HTML (I hope that
> doesn't come as a suprise to anyone) and making a viewer in Emacs for
> texi2html converted manuals similar to Info is IMHO a better
> solution. Or DocBook?  Hm.

I think implementing a new browser is more work than extending Info
with an image capability.

I don't want to use the nifty `i' command in Info -- and I don't
think that W3 supports this already.

kai
-- 
Silence is foo!

Re: Enhancements to options menu (was Re: Reveal mode)

[Stefan Monnier]

> 
> On Wed, 8 May 2002, Stefan Monnier wrote:
> 
> > As far as I can tell, there's nothing very specific in the info
> > format for indices.  There's just a convention that the top node
> > should have one or more entries with names like "Foo Index" and that
> > those subnodes should be made up of just one large menu of xrefs.
> > The same could be done for HTML, I'm sure.
> 
> "makeinfo --html" already creates the index nodes.
> 
> However, to use the indices efficiently (as opposed to just as large 
> menus with links), you need the browser to support the equivalent 
> of Info-index, Info-index-next, etc.  Otherwise, looking up a subject 
> becomes a much more tedious process, especially if the manual has several 
> large indices (e.g., the Emacs manual).
> 
> Is there any browser that supports such feature?  I'm not aware of such a 
> browser.

I thought we were talking about extending/changing info.el to support the
HTML format (or a subset of it).


	Stefan

Re: Enhancements to options menu (was Re: Reveal mode)

[Eli Zaretskii]

On Wed, 8 May 2002, Stefan Monnier wrote:

> I thought we were talking about extending/changing info.el to support the
> HTML format (or a subset of it).

Perhaps everybody else was, in which case I apologize for a gross 
misunderstanding.

If extending info.el is the issue, I tend to agree with Kai: implementing 
a whole new browser sounds like a large job.  Much larger than making it 
possible to display inline images in an Info file.

Re: Enhancements to options menu (was Re: Reveal mode)

[Karl Eichwalder]

"Stefan Monnier" <monnier+gnu/emacs@RUM.cs.yale.edu> writes:

Note, info relies on fixed font and fixed line length.

> What bothers me more is that HTML seems much less amenable to
> regexp-searching than the info format

I depends.  Most of the time I'm searching for a 1-word-expression.

But let's assume you are interested in "Software Foundation" -- search
for it and you will miss this location:

   You can also order copies of GNU Emacs from the Free Software
Foundation on CD-ROM.  This is a convenient and reliable way to get a
[...]

Using HTML would not be a big improvement: either work directly on Texi
files or use a lightweight DocBook format.

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.suse.de/~ke/                                  |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

Re: Enhancements to options menu (was Re: Reveal mode)

[Simon Josefsson]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> On Wed, 8 May 2002, Stefan Monnier wrote:
>
>> I thought we were talking about extending/changing info.el to support the
>> HTML format (or a subset of it).
>
> Perhaps everybody else was, in which case I apologize for a gross 
> misunderstanding.
>
> If extending info.el is the issue, I tend to agree with Kai: implementing 
> a whole new browser sounds like a large job.  Much larger than making it 
> possible to display inline images in an Info file.

But there could be other reasons for switching.  Perhaps HTML isn't
the best format, I agree with most of the reasons presented here,
although I'm sure it could be made to work.  But what about DocBook?
Doesn't GNOME use it?  KDE does, I think.  If so, making the Info
viewer support DocBook files as well could be useful.  All I'm saying
is that before someone starts to add features to the Info format (I
can think of more things than image support that could be useful when
documenting a GUI application), we should look at what other major
desktop applications are using.  And it isn't the Info format.

Re: Enhancements to options menu (was Re: Reveal mode)

[Simon Josefsson]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> It later occured to me that I don't see a good reason for extended the
>> Info format with these capabilities -- there is a perfectly fine
>> format for text with hyperlinks and images called HTML (I hope that
>> doesn't come as a suprise to anyone) and making a viewer in Emacs for
>> texi2html converted manuals similar to Info is IMHO a better
>> solution. Or DocBook?  Hm.
>
> I think implementing a new browser is more work than extending Info
> with an image capability.
>
> I don't want to use the nifty `i' command in Info -- and I don't
> think that W3 supports this already.

Right, the manual browser would continue to work the same, but the
file format need to be changed if images and stuff are to be
supported.  HTML could be made to work, I think.  DocBook seems to be
designed for these things, maybe it is better, I don't know.

Re: Enhancements to options menu (was Re: Reveal mode)

[Alan Shutko]

Simon Josefsson <jas@extundo.com> writes:

> But what about DocBook?  Doesn't GNOME use it?  KDE does, I think.
> If so, making the Info viewer support DocBook files as well could be
> useful.  

I may be wrong, but I don't think anyone uses DocBook files directly
for help support.  They all convert it into HTML and use a minimal
HTML browser.

Also, the help for other major desktop applications is lacking in
functionality, since it is usually just pulling up a HTML file in a
browser.  Rarely context-sensitive, doesn't do multi-page searching,
doesn't usually have an index at all, just a toc, rarely even uses
links of any sort.  Most Gnome and KDE docs are really small in
comparison to the Emacs manual, anyway, and they don't need to face
the same kinds of issues we do.  The only thing their docs have that
we don't is image embedding.

It might be useful to work on the tools the desktop projects use so
that they're more functional, since that would help all projects, but
I'm pretty sure they don't have anything we could use right now.

-- 
Alan Shutko <ats@acm.org> - In a variety of flavors!
Paul Revere was a tattle-tale.

Re: Enhancements to options menu (was Re: Reveal mode)

[Miles Bader]

Simon Josefsson <jas@extundo.com> writes:
> But what about DocBook?

DocBook is intended as a `source' format, like texinfo, and like html,
is based on sgml (boo, hiss!), with all the hair that entails.  It's
probably no easier to support than html (in fact, it may be more
complex).

> making the Info viewer support DocBook files as well could be useful.

See previous arguments re: html.

-Miles
-- 
"Most attacks seem to take place at night, during a rainstorm, uphill,
 where four map sheets join."   -- Anon. British Officer in WW I

Re: Enhancements to options menu (was Re: Reveal mode)

[Kai Großjohann]

Simon Josefsson <jas@extundo.com> writes:

> Right, the manual browser would continue to work the same, but the
> file format need to be changed if images and stuff are to be
> supported.  HTML could be made to work, I think.  DocBook seems to be
> designed for these things, maybe it is better, I don't know.

Since images are just one tag, why not include that?  Surely it can't
be so difficult to frob the code such that it groks "*image
/path/to/file::" in addition to "*note Some Node::".  The image tag
could be replaced with the image itself.

And then makeinfo needs to spit out the image tag when appropriate.

kai
-- 
Silence is foo!

Re: Enhancements to options menu (was Re: Reveal mode)

[Miles Bader]

Colin Walters <walters@debian.org> writes:
> Supporting *all* of HTML certainly would be an enormous effort.  But
> supporting the simple subset that texi2html generates shouldn't be hard.

Perhaps, but would doing so actually convey any benefit?

Here are four potential benefits from using something like html as an
intermediate representation for our docs:

 (1) We could use our browser to view other people's (html) docs 
 (2) Other people could view our docs in their html browser
 (3) We could use html-producing tools to make stuff for our browser
 (4) We could feed our docs to html-consuming tools

If implement only a small part of html, then we basically lose benefits
(1) and (3), because our browser won't be featureful enough.
Implementing a full-enough subset to actually be useful for these
purposes is probably quite hard.

If we also _extend_ html -- as we would probably want to do, to retain
all the benefits of info (like whole-document searching) -- then we
_also_ lose benefits (2) and (4).

So... what's the point, again?

-Miles
-- 
Somebody has to do something, and it's just incredibly pathetic that it
has to be us.  -- Jerry Garcia

Re: Enhancements to options menu (was Re: Reveal mode)

[Stefan Monnier]

> > What bothers me more is that HTML seems much less amenable to
> > regexp-searching than the info format
> 
> I depends.  Most of the time I'm searching for a 1-word-expression.
> 
> But let's assume you are interested in "Software Foundation" -- search
> for it and you will miss this location:

I'm talking about the regexp-searching that's part of the info.el code.
I.e. not for the user but for things like building the completion
table of the `i' and `m' commands.


	Stefan

Re: Enhancements to options menu (was Re: Reveal mode)

[Robert J. Chassell]

   ... Perhaps HTML isn't the best format, ...

As a documentation format, HTML is broken intrinsically.  HTML does
not distinguish between references to another document somewhere else
on the Internet and references to another part of the same document.

This means that you cannot design a program to search conveniently
through an HTML document that consists of more than one Web page.

Info, on the other hand, lets you navigate very conveniently through
a document using a regexp search.  It is still, after more than 15
years, the single most efficient on-line documentation format in
existence, surprising as that is, and all because you can undertake a
regexp search within the document.

You could design a special format for writing an HTML document that
enables you to navigate conveniently through a document.  This would be
an add-on to HTML.  

HTML's built-in failure was designed as a feature:  it was based on
the assumption that you would never create a document more than one
Web page long; and that that document should be able to link to any
other document on the World Wide Web.

   But what about DocBook?

You can create Info documents from DocBook; thus you gain efficient
navigation, which you lose when you convert the same document to HTML.

However, people who write in DocBook often fail to consider the
various output formats that are available.  For example, they may not
consider writing for a person who is driving a car and listening to
their work.  The authors tend to write as if every reader will *look*
at the page.  This is not a problem of the format, but of the
sociology of the document writing process.

A very good rule of thumb:  write your document so that a blind person
can follow it easily.  Then, even if no blind person ever reads it,
the document will be easily followed by a sighted person who is
looking at the document.  (Incidentally, this rule of thumb also
applies to Web page design.)

When you figure out how to show images in an Emacs session running
over a fast local network with a windowing system, please also, at the
same time, figure out how to show the same document to someone running
in a character-only mode over a slow network (my recent experience has
taken me below 300 baud), and at the same time, figure out how to
present the same document to someone who is `situationally blind'
while driving a car, or permanently blind.

-- 
    Robert J. Chassell                  bob@rattlesnake.com
    Rattlesnake Enterprises             http://www.rattlesnake.com

Re: Enhancements to options menu (was Re: Reveal mode)

[Karl Berry]

For the particular case of html documents derived from a texinfo source,
it would not be hard to write a simple cgi that does regexp search
through the document (or all documents installed in sibling directories
for that matter), or index search for that matter.  This would probably
make htmlified texinfo a lot easier to work with.

Re: Enhancements to options menu (was Re: Reveal mode)

[Alan Shutko]

karl@freefriends.org (Karl Berry) writes:

> For the particular case of html documents derived from a texinfo source,
> it would not be hard to write a simple cgi that does regexp search
[...]

Then, either you need to have docs installed in a webserver's space
that does CGI, or the browser needs to handle running CGIs.  Existing
browsers don't do this.

-- 
Alan Shutko <ats@acm.org> - In a variety of flavors!
No matter how cynical you get, it's impossible to keep up.

Re: Enhancements to options menu (was Re: Reveal mode)

[Karl Berry]

    Then, either you need to have docs installed in a webserver's space
    that does CGI, or the browser needs to handle running CGIs.  Existing
    browsers don't do this.

Of course it won't necessarily work in all configurations, and certainly
couldn't be automatically installed in all cases, but at least the
feature would be available for those who thought it important.  Although
such people have probably already implemented it.

Re: Enhancements to options menu (was Re: Reveal mode)

[Miles Bader]

karl@freefriends.org (Karl Berry) writes:
>     Then, either you need to have docs installed in a webserver's space
>     that does CGI, or the browser needs to handle running CGIs.  Existing
>     browsers don't do this.
> 
> Of course it won't necessarily work in all configurations, and certainly
> couldn't be automatically installed in all cases, but at least the
> feature would be available for those who thought it important.

Given what I know about current practice, it sounds like it wouldn't be
supported _most_ of time (that is, that this sort of thing basically
isn't supported unless you run a webserver, which is very hard to
ensure) -- and global searching is a pretty big thing to lose.

-Miles
-- 
`The suburb is an obsolete and contradictory form of human settlement'

Re: Enhancements to options menu (was Re: Reveal mode)

[Eli Zaretskii]

> From: Simon Josefsson <jas@extundo.com>
> Date: Wed, 08 May 2002 17:28:04 +0200
> 
> > If extending info.el is the issue, I tend to agree with Kai: implementing 
> > a whole new browser sounds like a large job.  Much larger than making it 
> > possible to display inline images in an Info file.
> 
> But there could be other reasons for switching.  Perhaps HTML isn't
> the best format, I agree with most of the reasons presented here,
> although I'm sure it could be made to work.  But what about DocBook?

My gut feeling is that switching to _any_ other format would be a lot
of effort for little or no benefit.  The number of features, in Emacs
and elsewhere, that are based on Info is enormous.

By contrast, adding an ability to display images in Info files is a
much simpler job.

Re: Enhancements to options menu (was Re: Reveal mode)

[Richard Stallman]

    Note, info relies on fixed font and fixed line length.

How is that?  I don't think so.

Re: Enhancements to options menu (was Re: Reveal mode)

[Karl Eichwalder]

Richard Stallman <rms@gnu.org> writes:

> How is that?  I don't think so.

In other words: The Info buffer does no auto-wrapping -- if you
increase or decrease the window the line length will always stay the
same.

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.suse.de/~ke/                                  |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

Re: Enhancements to options menu (was Re: Reveal mode)

[Eli Zaretskii]

> From: Karl Eichwalder <keichwa@gmx.net>
> Date: Thu, 09 May 2002 18:53:16 +0200
> 
> In other words: The Info buffer does no auto-wrapping -- if you
> increase or decrease the window the line length will always stay the
> same.

But that's how Emacs behaves in any buffer: they never auto-wrap.
Such an auto-wrapping is AFAIK a TODO item.

Re: Enhancements to options menu (was Re: Reveal mode)

[Karl Eichwalder]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

> But that's how Emacs behaves in any buffer: they never auto-wrap.

Yes, and most of the time that's a good thing (IMO).  Emacs/W3 behaves
different; changing the width of the window you can force W3 to adjust
the filling.

> Such an auto-wrapping is AFAIK a TODO item.

I guess you are talking about this item:

    * Implement primitive and higher-level functions to allow filling
      properly with variable-pitch faces.

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.suse.de/~ke/                                  |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

Re: Enhancements to options menu (was Re: Reveal mode)

[Eli Zaretskii]

> From: Karl Eichwalder <keichwa@gmx.net>
> Date: Thu, 09 May 2002 20:26:45 +0200
> 
> > Such an auto-wrapping is AFAIK a TODO item.
> 
> I guess you are talking about this item:
> 
>     * Implement primitive and higher-level functions to allow filling
>       properly with variable-pitch faces.

No, the one before it:

    * Implement something better than the current Refill mode.  This
      probably needs some primitive support.

Re: Enhancements to options menu (was Re: Reveal mode)

[Karl Eichwalder]

Alan Shutko <ats@acm.org> writes:

> I may be wrong, but I don't think anyone uses DocBook files directly
> for help support.  They all convert it into HTML and use a minimal
> HTML browser.

No. Yelp is the new help browser for GNOME 2.0.  It supports documents
written in Docbook XML (= normalized SGML files), man pages and info
pages.

    http://ftp.gnome.org/pub/GNOME/pre-gnome2/sources/yelp/

> Most Gnome and KDE docs are really small in comparison to the Emacs
> manual, anyway, and they don't need to face the same kinds of issues
> we do.

Maybe most, but not all.  The Gimp documentation is comprehensive (I
admit I didn't try to view it using yelp).

> The only thing their docs have that we don't is image embedding.

You can apply your own stylesheets (XSL) to tweak the view of the
document -- in Emacs you can customize faces.

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.suse.de/~ke/                                  |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

Re: Enhancements to options menu (was Re: Reveal mode)

[Eli Zaretskii]

On Sun, 12 May 2002, Karl Eichwalder wrote:

> Alan Shutko <ats@acm.org> writes:
> 
> > I may be wrong, but I don't think anyone uses DocBook files directly
> > for help support.  They all convert it into HTML and use a minimal
> > HTML browser.
> 
> No. Yelp is the new help browser for GNOME 2.0.  It supports documents
> written in Docbook XML (= normalized SGML files), man pages and info
> pages.

It may be of interest that the latest Texinfo release 4.2 can produce 
DocBook and/or XML from a Texinfo source.