Re: Suggestions for mode-line-format changes

Re: Suggestions for mode-line-format changes

[Stefan Monnier]

Am I the only one whose `which-func-mode' string is way too far
on the right so it most of the time can't be seen (because of the
major/minor mode string which says (Emacs-Lisp ElDoc CDoc Outl Fly).


	Stefan


BTW: There is redundancy between the menu-bar and the minor-mode list in the
     mode-line since both CheckDoc and Outline have their menu-bar entry.
     It really would be great if CheckDoc could easily add itself to the
     Emacs-Lisp menu instead of having its own menu.
     Sadly, keymap-merging for menus doesn't work, so it would have to
     add/remove itself from the emacs-lisp-mode-map rather than simply use
     a minor-mode-map as it currently does.

Suggestions for mode-line-format changes

[Kim F. Storm]

Now that the mode-line-position information has been moved
from the end of the mode line, and vc-mode is moved there too,
the space between the buffer name and the mode-line-modes
has become pretty crowded.

Now, if you enable display-time and display-battery,
which adds time and battery status, e.g. 15:57 [95%],
to that part of the mode line as well, it's a total mess.

My suggestion is to move the global-mode-string to the
end of the mode line; the cost is that the time and
battery status isn't always shown (especially in
partial width windows).


Also, I would like to suggest an alternative presentation
of the position, line number, and column number.

The current presentation is like

        L1 C0 Top
        L172 C23 43%
        L341 C0 Bot

which I find quite annoying to look at.

I've been using the following alternative for quite some
time, and I find it much easier on the eyes:

        Top (1,0)
        43% (172,23)
        Bot (341,0)

If only one of line-number-mode or column-number-mode is enabled,
this doesn't make much sense, so I use the following formats:

        Top L1
        43% C23
        Bot L341

To try the suggested format, just execute this (and toggle column and
line number mode as you like):

(let ((help-echo "mouse-1: select (drag to resize), mouse-2: delete others, mouse-3: delete"))
  (setq-default mode-line-position
    `((-3 . ,(propertize "%p" 'help-echo help-echo))
      (line-number-mode 
       ((column-number-mode
	 (,(propertize " (%l,%c)" 'help-echo help-echo))
	 (,(propertize " L%l" 'help-echo help-echo))))
       ((column-number-mode
	 (,(propertize " C%c" 'help-echo help-echo))))))))


What do you think?

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

Re: Suggestions for mode-line-format changes

[Romain FRANCOISE]

Kim F Storm writes:

> I've been using the following alternative for quite some
> time, and I find it much easier on the eyes:

>         Top (1,0)
>         43% (172,23)
>         Bot (341,0)

The problem with this is that for the newcomer, it's not obvious that
the numbers refer to the current column and line.  I agree that your
solution is compact and acceptable for a trained eye, but I wouldn't
recommend it as a default setting.  And for the record, I like the
current default setting, it's easily readable and clearly
distinguishes line and column numbers, so my vote goes to "status quo"
on this issue.

Just my 2c,

Romain.
-- 
Romain FRANCOISE <romain@orebokech.com> | But you don't care for me and
it's a miracle -- http://orebokech.com/ | I don't care now for anybody.

Re: Suggestions for mode-line-format changes

[Richard Stallman]

Your ideas sound good--would you please go ahead and implement them?

Re: Suggestions for mode-line-format changes

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> Your ideas sound good--would you please go ahead and implement them?

Done.

I managed to solve the problem I had with padding of mode-line-position 
(discussed in another mail); the trick was to specify the padding for
the %l/%c part, rather than the whole mode-line-position.

However, I still think it is a bug that we cannot use "precision" on a
mode-line-element nested inside a "padded" mode-line-element.

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

Re: Suggestions for mode-line-format changes

[Richard Stallman]

    However, I still think it is a bug that we cannot use "precision" on a
    mode-line-element nested inside a "padded" mode-line-element.

In principal it would be good to make all features orthogonal, but I
tend to think this is not as important as other things we can do.

Re: Suggestions for mode-line-format changes

[Kim F. Storm]

I wrote:

> Now that the mode-line-position information has been moved
> from the end of the mode line, and vc-mode is moved there too,
> the space between the buffer name and the mode-line-modes
> has become pretty crowded.
> 

Actually, I think the new position of "mode-line-position" in the mode line
is a drawback compared to the former position at the end of the mode line!

Try turning on column-number-mode, goto to the first line of a
non-empty buffer and hold down the right arrow key to advance through
the characters and lines of the buffer.

Notice how the mode line information to the right of the
mode-line-position starts jumping forth and back when the column goes
from 9 to 10 and from the end of line column back to 0.

Likewise, if you just start writing in the buffer, the same jumpyness
is seen in the mode line as you enter the 10th character of a line
and you press RET.

IMO, this is really, really annoying.  I never saw any such jumpyness
with the old position.


I liked the old position better, but if we want to keep it in the new
position, I think padding of the whole mode-line-position
[specified inside mode-line-position itself, of course] should be
added.

Using my suggested format, I tried to add padding like this:

        (setq-default mode-line-position 
                      '((15 (-3 . "%p") " (%l,%c)")))

but this doesn't work as the entire padding is done to the end of the
%p part.

I then tried

        (setq-default mode-line-position 
                      '((15 "" (-3 . "%p") " (%l,%c)")))

but then the "" is padded to 15 spaces which doesn't help either.


The following works by padding at the end of the combined string, but
then the "Bottom" string isn't truncated to "Bot":

(setq-default mode-line-position 
	      '((15 "%p (%l,%c)")))


It seems that it doesn't work to combine padding and trunction like
        (15 (-3 ...) ...)

That's a bug IMO.


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

Re: Suggestions for mode-line-format changes

[Kenichi Handa]

In article <5xk7mlfsvf.fsf@kfs2.cua.dk>, storm@cua.dk (Kim F. Storm) writes:
> Now that the mode-line-position information has been moved
> from the end of the mode line, and vc-mode is moved there too,
> the space between the buffer name and the mode-line-modes
> has become pretty crowded.

> Now, if you enable display-time and display-battery,
> which adds time and battery status, e.g. 15:57 [95%],
> to that part of the mode line as well, it's a total mess.

I'd like to display such global information not in the mode
line but, for instance, at the right end of menu bar, or
tool bar if they exist.  Such an area can also be used for
displaying:
	o multibyte or unibyte session
	o current language environment
But, I don't know how it is difficult.

By the way, I'm recently using this code to make Emacs
use frame title for displaying time-string.

(add-hook
 'display-time-mode-hook
 #'(lambda () 
     (setq global-mode-string
	   (delete 'display-time-string global-mode-string))))

(add-hook
 'display-time-hook
 #'(lambda ()
     (modify-frame-parameters 
      nil
      `((title . ,display-time-string)))))

---
Ken'ichi HANDA
handa@etl.go.jp

Re: Suggestions for mode-line-format changes

[Miles Bader]

Kenichi Handa <handa@etl.go.jp> writes:
> > Now, if you enable display-time and display-battery,
> > which adds time and battery status, e.g. 15:57 [95%],
> > to that part of the mode line as well, it's a total mess.
> 
> I'd like to display such global information not in the mode
> line but, for instance, at the right end of menu bar, or
> tool bar if they exist.

Hmm, that seems like a great idea (for global info like that).

I think the menu-bar would be better, since I don't use a tool-bar...:-/

I don't think it would be too hard to hack something like that into the
lucid toolkit that comes with emacs, but I have no idea about other
toolkits.

-Miles
-- 
`Cars give people wonderful freedom and increase their opportunities.
 But they also destroy the environment, to an extent so drastic that
 they kill all social life' (from _A Pattern Language_)

Re: Suggestions for mode-line-format changes

[Kim F. Storm]

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

> Kenichi Handa <handa@etl.go.jp> writes:
> > > Now, if you enable display-time and display-battery,
> > > which adds time and battery status, e.g. 15:57 [95%],
> > > to that part of the mode line as well, it's a total mess.
> > 
> > I'd like to display such global information not in the mode
> > line but, for instance, at the right end of menu bar, or
> > tool bar if they exist.
> 
> Hmm, that seems like a great idea (for global info like that).
> 
> I think the menu-bar would be better, since I don't use a tool-bar...:-/
> 
> I don't think it would be too hard to hack something like that into the
> lucid toolkit that comes with emacs, but I have no idea about other
> toolkits.

I guess it could always be done using a "tool-tip" like approach, ie.
by displaying the information in a separate "global-mode-frame".

That would allow users to position that frame on title-bar,
menu-bar, tool-bar, or below the emacs frame; but that could be
used for more things (e.g. ediff frame) and other stuff as well.

Would need some ways to control where that frame is displayed
relative to the currently active emacs frame.

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

Re: Suggestions for mode-line-format changes

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> > I don't think it would be too hard to hack something like that into the
> > lucid toolkit that comes with emacs, but I have no idea about other
> > toolkits.
> 
> I guess it could always be done using a "tool-tip" like approach, ie.
> by displaying the information in a separate "global-mode-frame".

Don't want.  I want it in the main window (little independent X windows
are generally pretty icky; see ediff for a particularly stupid and
annoying example).

-Miles
-- 
A zen-buddhist walked into a pizza shop and
said, "Make me one with everything."

Re: Suggestions for mode-line-format changes

[Kenichi Handa]

In article <buolm70eas1.fsf@mcspd15.ucom.lsi.nec.co.jp>, Miles Bader <miles@lsi.nec.co.jp> writes:
>>  I guess it could always be done using a "tool-tip" like approach, ie.
>>  by displaying the information in a separate "global-mode-frame".

> Don't want.  I want it in the main window (little independent X windows
> are generally pretty icky; see ediff for a particularly stupid and
> annoying example).

If you mean `frame' by `window', I fully agree.

---
Ken'ichi HANDA
handa@etl.go.jp

Re: Suggestions for mode-line-format changes

[Miles Bader]

huug <huug.at.gmane@xs4all.nl> writes:
> > Don't want.  I want it in the main window (little independent X
> > windows are generally pretty icky; see ediff for a particularly
> > stupid and annoying example).
> 
> If you mean ediff should use a more tool-tip like frame, I agree.

No, I mean ediff shouldn't use the stupid little `command frame'.
It shouldn't use any new frames at all, it should just make the ediff
commands available in the two buffers being diffed.

[ediff's user interface seems generally pretty bad; I like the
functionality, but never use it because it drives me nuts every time I
try]

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

Re: Suggestions for mode-line-format changes

[Richard Stallman]

    [ediff's user interface seems generally pretty bad; I like the
    functionality, but never use it because it drives me nuts every time I
    try]

I feel the same--I tried it once and got too confused.

I don't know whether fixing this would require major changes
or perhaps just fixing a few details.

Re: Suggestions for mode-line-format changes

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     [ediff's user interface seems generally pretty bad; I like the
>     functionality, but never use it because it drives me nuts every time I
>     try]
> 
> I feel the same--I tried it once and got too confused.
> 
> I don't know whether fixing this would require major changes
> or perhaps just fixing a few details.

I'd suggest giving it another try.  The GUI is a little akward to get
used to, but ediif is really too good to reject simply because of that.

I couldn't live without it; on the projects I work on I often have to
install bug fixes on several release brances, and ediff makes that
quite easy!


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

Re: Suggestions for mode-line-format changes

[Miles Bader]

On Mon, Aug 26, 2002 at 01:36:10AM +0200, Kim F. Storm wrote:
> I'd suggest giving it another try.  The GUI is a little akward to get
> used to, but ediff is really too good to reject simply because of that.

So the best solution would be the same functionality with a better UI.

-miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: Suggestions for mode-line-format changes

[Michael Kifer]

Somebody>     [ediff's user interface seems generally pretty bad; I like the
Somebody>     functionality, but never use it because it drives me nuts every time I
Somebody>     try]

RMS> I feel the same--I tried it once and got too confused.
RMS> 
RMS> I don't know whether fixing this would require major changes
RMS> or perhaps just fixing a few details.

Kim Storm> I'd suggest giving it another try.  The GUI is a little akward to get
Kim Storm> used to, but ediff is really too good to reject simply because of that.

Miles Bader> So the best solution would be the same functionality with a better UI.


I am open to suggestions, but I don't have much time to make major changes.
Couple of times (the above is perhaps the third) I received general
complaints about how bad ediff UI is (in almost exactly the same words as
above with no useful info attached), but when I asked to be more specific the
complainers did not bother to reply.

	--michael 


PS. On the other hand, I receive tons of email attesting to the contrary.

PPS. I am also not averse to the idea that somebody takes over the maintenance of
     ediff.

Re: Suggestions for mode-line-format changes

[Miles Bader]

Michael Kifer <kifer@cs.sunysb.edu> writes:
> Somebody>     [ediff's user interface seems generally pretty bad; I
> Somebody>     like the functionality, but never use it because it
> Somebody>     drives me nuts every time I try]
> 
> I am open to suggestions, but I don't have much time to make major changes.

I don't think anybody expects you to, certainly not without a real plan,
and hopefully anyone who really wants a change would do the work.

Anyway, though I don't like ediff's UI, it's not entirely clear to me
what a better UI would look like; perhaps discussion could turn up
some ideas.

I think my main problem with ediff is that it seems way too stateful --
it sets up an `ediff session' and puts up a special `control frame' (or
window), and generally seems very heavyweight.  I guess many people like
this (it's sort of like many dedicated GUI diff programs), but I don't;
it's very un-emacsy.  When I see all that state, I worry what happens if
I forget that I'm ediffing and delete a buffer or change a buffer, &c.
Maybe this worry is unwarranted, but I think it's kind of natural given
the general style of the ediff UI.

Compared to other programs, emacs gives the user much more freedom over
the configuration of windows, etc., and the ability to freely switch to
other tasks, so very stateful UIs often cause problems.

[The same `stateful' complaint could be made about e.g. Gnus, but I find
that when I want to use ediff, I also want to mess with CVS, visit other
source files, etc., and generally mess up the nice window configuration
ediff set up; this doesn't generally seem to happen with Gnus.]

I'd prefer that _all_ ediff state be contained within the two buffers
being diffed; if I kill them both, poof, no more ediff state (if I kill
only one, who knows, but presumably an error when you try to perform an
ediff operation).  [Maybe this is the case already, and I'm being fooled
by the appearance of the UI; what happens when you try two simulaneous
ediff sessions, for instance?]

This of course means that something has to be done about ediff commands;
I'd be happy with a simple command-mode vs. edit-mode toggle (look at
`diff-mode' for a particularly elegant implementation, BTW -- it puts
all the special single-letter command shortcuts on a minor-mode keymap
enabled by `buffer-read-only', so when the file's editable, you can edit
it, and you can just do toggle-read-only to get the convenient shortcut
commands).

Anyway, that's my take.

> PS. On the other hand, I receive tons of email attesting to the contrary.

Well, I think there's no doubt that ediff contains some great
functionality.

-Miles
-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

Re: Suggestions for mode-line-format changes

[Michael Kifer]

Miles,
If I understand you correctly, almost everything that you have described is
already there and is available from the menus.

80% of ediff's functionality can be figured out without reading the
manual. Did you ever try to hit the "?" mark in that small window or try to
experiment with Menubar.Tools."Ediff Miscellanea"?
But RTFM is always a good idea.

Anyway, if you have a better design, the field is wide open. I just want
to air my opinion on one suggestion of yours: If all the state is contained
in *both* buffers (or 3 buffers), as you suggest, then it is a *bad*
idea. The state should be in *one* buffer, as it is in Ediff. It was
designed this way because it is important to be able to run multiple
simultaneous diffing sessions that involve overlapping buffers or
parts of buffers.

One thing that Ediff doesn't do (among the things that you have listed) is
to give the user complete control of how exactly the windows should look
like. It has its own idea (although it is more flexible than you probably
think). But if you RTMF, you will see that all this is just one
variable/function, which you can customize. If you have the time and a
design, you can write your own window setup function and offer it to the
world.


	--michael 


> Michael Kifer <kifer@cs.sunysb.edu> writes:
> > Somebody>     [ediff's user interface seems generally pretty bad; I
> > Somebody>     like the functionality, but never use it because it
> > Somebody>     drives me nuts every time I try]
> > 
> > I am open to suggestions, but I don't have much time to make major changes.
> 
> I don't think anybody expects you to, certainly not without a real plan,
> and hopefully anyone who really wants a change would do the work.
> 
> Anyway, though I don't like ediff's UI, it's not entirely clear to me
> what a better UI would look like; perhaps discussion could turn up
> some ideas.
> 
> I think my main problem with ediff is that it seems way too stateful --
> it sets up an `ediff session' and puts up a special `control frame' (or
> window), and generally seems very heavyweight.  I guess many people like
> this (it's sort of like many dedicated GUI diff programs), but I don't;
> it's very un-emacsy.  When I see all that state, I worry what happens if
> I forget that I'm ediffing and delete a buffer or change a buffer, &c.
> Maybe this worry is unwarranted, but I think it's kind of natural given
> the general style of the ediff UI.
> 
> Compared to other programs, emacs gives the user much more freedom over
> the configuration of windows, etc., and the ability to freely switch to
> other tasks, so very stateful UIs often cause problems.
> 
> [The same `stateful' complaint could be made about e.g. Gnus, but I find
> that when I want to use ediff, I also want to mess with CVS, visit other
> source files, etc., and generally mess up the nice window configuration
> ediff set up; this doesn't generally seem to happen with Gnus.]
> 
> I'd prefer that _all_ ediff state be contained within the two buffers
> being diffed; if I kill them both, poof, no more ediff state (if I kill
> only one, who knows, but presumably an error when you try to perform an
> ediff operation).  [Maybe this is the case already, and I'm being fooled
> by the appearance of the UI; what happens when you try two simulaneous
> ediff sessions, for instance?]
> 
> This of course means that something has to be done about ediff commands;
> I'd be happy with a simple command-mode vs. edit-mode toggle (look at
> `diff-mode' for a particularly elegant implementation, BTW -- it puts
> all the special single-letter command shortcuts on a minor-mode keymap
> enabled by `buffer-read-only', so when the file's editable, you can edit
> it, and you can just do toggle-read-only to get the convenient shortcut
> commands).
> 
> Anyway, that's my take.
> 
> > PS. On the other hand, I receive tons of email attesting to the contrary.
> 
> Well, I think there's no doubt that ediff contains some great
> functionality.
> 
> -Miles
> -- 
> `...the Soviet Union was sliding in to an economic collapse so comprehensive
>  that in the end its factories produced not goods but bads: finished products
>  less valuable than the raw materials they were made from.'  [The Economist]
> 

Re: Suggestions for mode-line-format changes

[Miles Bader]

Michael Kifer <kifer@cs.sunysb.edu> writes:
> If I understand you correctly, almost everything that you have described is
> already there and is available from the menus.

Well, either you don't understand me correctly, or else the menus and
documentation (which I did read) are designed for those smarter or more
patient than I.  As far as I can see, _none_ of what I described is
available.

In particular, it appears that you _always_ need a control frame/window,
and that ediff commands _only_ work in the control frame/window (even if
I type `M-x ediff-next-difference' in one of the buffers being diffed,
it just gives me an error saying that).

> 80% of ediff's functionality can be figured out without reading the
> manual.  Did you ever try to hit the "?" mark in that small window or
> try to experiment with Menubar.Tools."Ediff Miscellanea"?
> But RTFM is always a good idea.

Of course.  It shows lots of handy commands -- but `how to find ediff
commands' wasn't what I was complaining about.

> If all the state is contained in *both* buffers (or 3 buffers), as you
> suggest, then it is a *bad* idea.  The state should be in *one*
> buffer, as it is in Ediff.  It was designed this way because it is
> important to be able to run multiple simultaneous diffing sessions
> that involve overlapping buffers or parts of buffers.

It sounds like the best thing to do is have all ediff state contained
in a lisp value, which is pointed to by whatever buffers, but
presumably this would be a big change to the code.

-Miles
-- 
[|nurgle|]  ddt- demonic? so quake will have an evil kinda setting? one that 
            will  make every christian in the world foamm at the mouth? 
[iddt]      nurg, that's the goal 

Re: Suggestions for mode-line-format changes

[Michael Kifer]

Miles Bader <miles@gnu.org> said:
>
> Michael Kifer <kifer@cs.sunysb.edu> writes:
> > If I understand you correctly, almost everything that you have described is
> > already there and is available from the menus.
> 
> Well, either you don't understand me correctly, or else the menus and
> documentation (which I did read) are designed for those smarter or more
> patient than I.  As far as I can see, _none_ of what I described is
> available.
> 
> In particular, it appears that you _always_ need a control frame/window,
> and that ediff commands _only_ work in the control frame/window (even if
> I type `M-x ediff-next-difference' in one of the buffers being diffed,
> it just gives me an error saying that).

Yes, you always need the control buffer. But you can hide it and the other
windows if you need to do something else. There is a mechanism to easily
find suspended ediff sessions and resume them. Your complaint was about the
inability to switch to other emacs jobs and I am saying that this is not the
case.

It seems that none of what you explicitly listed in your original message
is the real problem. Instead, you are complaining about the design decision
that the small control window must be present at all times.

In this regard, I think you might not have understood what I said about a
bad suggestion in your previous message. The same buffer can be involved in
different ediff sessions.  I consider this essential. You can't just start
typing commands into a buffer being diffed without first indicating which
session the buffer is involved in is current.

The UI by which you indicate this is not present in ediff, but can be
added, because each buffer already knows the set of sessions it is in.
However, I won't be the one to implement this because I think it is going
to be confusing and is not necessary.

> > If all the state is contained in *both* buffers (or 3 buffers), as you
> > suggest, then it is a *bad* idea.  The state should be in *one*
> > buffer, as it is in Ediff.  It was designed this way because it is
> > important to be able to run multiple simultaneous diffing sessions
> > that involve overlapping buffers or parts of buffers.
> 
> It sounds like the best thing to do is have all ediff state contained
> in a lisp value, which is pointed to by whatever buffers, but
> presumably this would be a big change to the code.

It is already contained in one place -- the control buffer.
It is possible to make this buffer invisible as I indicated above and
instead implement a mechanism by which you indicate the current control session.
But I think this is a bad idea. This is how emerge works, and I don't like
its interface. I want to be able to edit the buffers without typing special
commands by just moving the mouse there.



	--michael 

Re: Suggestions for mode-line-format changes

[Miles Bader]

Michael Kifer <kifer@cs.sunysb.edu> writes:
> In this regard, I think you might not have understood what I said about a
> bad suggestion in your previous message.

No, I understood what you meant.

> The same buffer can be involved in different ediff sessions.  I
> consider this essential.  You can't just start typing commands into a
> buffer being diffed without first indicating which session the buffer
> is involved in is current.

Sure, it's true that the current UI might be best for very complex
situations like that -- but frankly, for me at least, the default is
_very simple_ situations, where it _is_ quite reasonable to have a
unique mapping of text-buffer->ediff-session.

I'd be happy if ediff could give me my preferred UI most of the time,
but require me switch to the complex UI for those (very, very, rare)
circumstances when I need to.

> The UI by which you indicate this is not present in ediff, but can be
> added, because each buffer already knows the set of sessions it is in.

Ok.  If I get around too it, I'll see if I can add enough features to
ediff to allow it to use an interface like I've described.

> It is already contained in one place -- the control buffer.  It is
> possible to make this buffer invisible as I indicated above and
> instead implement a mechanism by which you indicate the current
> control session.

I'd like it so that command in one of the source buffers simply mapped
to the control buffer, which would stay hidden (even when `in use').

> But I think this is a bad idea. This is how emerge works, and I don't
> like its interface.

That's OK; we're even, I guess... :-)

-Miles
-- 
Run away!  Run away!

Re: Suggestions for mode-line-format changes

[Michael Kifer]

>>>>> "Miles" == Message from Miles Bader <<miles@lsi.nec.co.jp> > writes:

    >> It is already contained in one place -- the control buffer.  It is
    >> possible to make this buffer invisible as I indicated above and
    >> instead implement a mechanism by which you indicate the current
    >> control session.

    Miles> I'd like it so that command in one of the source buffers simply mapped
    Miles> to the control buffer, which would stay hidden (even when `in use').

This info is present, since each buffer has a local var that contain the
list of control buffers of the ediff sessions related to it.

    >> But I think this is a bad idea. This is how emerge works, and I don't
    >> like its interface.

    Miles> That's OK; we're even, I guess... :-)

Grin. But I wasn't trying to get at you. I really actively disliked emerge's
interface, which was one of the reasons why I didn't use it, while at the
same time stealing many other ideas from this package.


	--michael 

Re: Suggestions for mode-line-format changes

[Miles Bader]

Michael Kifer <kifer@cs.sunysb.edu> writes:
>     Miles> I'd like it so that command in one of the source buffers
>     Miles> simply mapped to the control buffer, which would stay
>     Miles> hidden (even when `in use').
> 
> This info is present, since each buffer has a local var that contain the
> list of control buffers of the ediff sessions related to it.

Ok; so perhaps the following would suffice:

  * A minor-mode that just contains a keymap full of appropriate
    commands that redirect to the first ediff control-buffer in the list
    (perhaps conditionalized on buffer-read-only like in diff-mode).
    It looks like `ediff-prepare-buffer-hook' could be used to turn on
    the minor mode in each source buffer.

  * An ediff window-configuration function that always keeps the
    control-window hidden.

-Miles
-- 
97% of everything is grunge

Re: Suggestions for mode-line-format changes

[Michael Kifer]

> Michael Kifer <kifer@cs.sunysb.edu> writes:
> >     Miles> I'd like it so that command in one of the source buffers
> >     Miles> simply mapped to the control buffer, which would stay
> >     Miles> hidden (even when `in use').
> > 
> > This info is present, since each buffer has a local var that contain the
> > list of control buffers of the ediff sessions related to it.
> 
> Ok; so perhaps the following would suffice:
> 
>   * A minor-mode that just contains a keymap full of appropriate
>     commands that redirect to the first ediff control-buffer in the list
>     (perhaps conditionalized on buffer-read-only like in diff-mode).
>     It looks like `ediff-prepare-buffer-hook' could be used to turn on
>     the minor mode in each source buffer.
> 
>   * An ediff window-configuration function that always keeps the
>     control-window hidden.
> 
> -Miles

Pretty much. However, I think that defaulting to one of the active control
sessions is no good. Could be too confusing and frustrating.
Need a mechanism to set the default session.

Any takers? :-)

m

Re: Suggestions for mode-line-format changes

[Miles Bader]

Michael Kifer <kifer@cs.sunysb.edu> writes:
> >   * A minor-mode that just contains a keymap full of appropriate
> >     commands that redirect to the first ediff control-buffer in the list
> >     (perhaps conditionalized on buffer-read-only like in diff-mode).
> >     It looks like `ediff-prepare-buffer-hook' could be used to turn on
> >     the minor mode in each source buffer.
> 
> Pretty much.  However, I think that defaulting to one of the active control
> sessions is no good.  Could be too confusing and frustrating.
> Need a mechanism to set the default session.

I think that 99% of the time, the control-buffer list will only have one
entry anyway, and it's obviously harmless to `default' in _that_ case!

I also think it's a good idea to worry about the common case before the
worst case, especially since the worst case is already covered, by the
existing control-window mechanism.

Note that:

  * I'm not suggesting that this minor-mode be turned on by default,
    just that it be available for people like me that don't like the
    normal UI (though perhaps with the `buffer-read-only'
    conditionalization, it wouldn't hurt to have it on by default).

  * If the control buffer isn't hidden, you can use it just like
    always, so no functionality is really lost.  I suspect that if
    people start having multiple simultaneous ediffs on the same
    buffer, they're going to want to use the control-buffer windows
    anyway, for the reasons you gave earlier.

    If they want to use the source-buffer minor-mode commands in
    _addition_ to the control-buffer in a `complex' ediff situation, a
    good solution might be to simply reorder each source-buffer's
    control-buffer list everytime an ediff command is given, so that the
    command-giving control-buffer is first in the source-buffer's list.

    This way, the `ediff session' invoked by the minor-mode will always
    be the most recent one invoked via control-buffer, without needing
    any additional command for setting defaults or whatever.  This seems
    like a straight-forward solution that will usually do the right
    thing even in complex cases.

-miles
-- 
`Cars give people wonderful freedom and increase their opportunities.
 But they also destroy the environment, to an extent so drastic that
 they kill all social life' (from _A Pattern Language_)

Re: Suggestions for mode-line-format changes

[Michael Kifer]

> Michael Kifer <kifer@cs.sunysb.edu> writes:
> > >   * A minor-mode that just contains a keymap full of appropriate
> > >     commands that redirect to the first ediff control-buffer in the list
> > >     (perhaps conditionalized on buffer-read-only like in diff-mode).
> > >     It looks like `ediff-prepare-buffer-hook' could be used to turn on
> > >     the minor mode in each source buffer.
> > 
> > Pretty much.  However, I think that defaulting to one of the active control
> > sessions is no good.  Could be too confusing and frustrating.
> > Need a mechanism to set the default session.
> 
> I think that 99% of the time, the control-buffer list will only have one
> entry anyway, and it's obviously harmless to `default' in _that_ case!
> 
> I also think it's a good idea to worry about the common case before the
> worst case, especially since the worst case is already covered, by the
> existing control-window mechanism.
> 
> Note that:
> 
>   * I'm not suggesting that this minor-mode be turned on by default,
>     just that it be available for people like me that don't like the
>     normal UI (though perhaps with the `buffer-read-only'
>     conditionalization, it wouldn't hurt to have it on by default).
> 
>   * If the control buffer isn't hidden, you can use it just like
>     always, so no functionality is really lost.  I suspect that if
>     people start having multiple simultaneous ediffs on the same
>     buffer, they're going to want to use the control-buffer windows
>     anyway, for the reasons you gave earlier.
> 
>     If they want to use the source-buffer minor-mode commands in
>     _addition_ to the control-buffer in a `complex' ediff situation, a
>     good solution might be to simply reorder each source-buffer's
>     control-buffer list everytime an ediff command is given, so that the
>     command-giving control-buffer is first in the source-buffer's list.
> 
>     This way, the `ediff session' invoked by the minor-mode will always
>     be the most recent one invoked via control-buffer, without needing
>     any additional command for setting defaults or whatever.  This seems
>     like a straight-forward solution that will usually do the right
>     thing even in complex cases.
> 
> -miles

I don't know. I don't like programs that know better than I what I should
be doing. Note also that if you have 2 buffers, the order of ediff sessions
in which they are involved might be different. This would lead to even more
confusion. I just don't see the benefits. All these complications
for the privilege of being able to hold your mouse over a different window
than now?

Of course, if you implement it and people like this -- all the power to you!


	--michael

Re: Suggestions for mode-line-format changes

[Miles Bader]

kifer@cs.stonybrook.edu (Michael Kifer) writes:
> I don't know.  I don't like programs that know better than I what I should
> be doing.

I think the heuristic I mentioned would probably be right almost all of
the time (and _all of the time_ for the overwhelmingly common case where
you're not doing simultaneous ediffs on the same file).

> Note also that if you have 2 buffers, the order of ediff sessions in
> which they are involved might be different.  This would lead to even
> more confusion.

Perhaps -- in the case where you have multiple simultaneous ediffs with
overlapping sets of buffers.  How often do you do this?

[In fact, I think the `most recent' behavior would be fairly reasonable,
even in this case]

You seem to be saying `Look, in this highly complex case, it will be
confusing!  Abort!'

This seems odd for two reasons -- 

 (1) I think most people use ediff in a fairly simple way, so wouldn't
     it be good to optimize for that?  One way to do this is to provide
     good defaults (and perhaps a way to override them for unusual cases).

 (2) The cases you mention, with multiple overlapping ediff sessions,
     are simply confusing, full-stop, regardless of what this minor-mode
     does.  You're probably better off using the control-window in such
     cases.

     Maybe you could make it a bit better by providing ways to override
     the defaults for such rare situations, but it doesn't mean you
     should avoid defaults altogether.

> I just don't see the benefits.  All these complications for the
> privilege of being able to hold your mouse over a different window
> than now?

Er, I don't use a mouse very much when I use emacs.  Perhaps that's one
reason why I'm annoyed by ediff's interface and you're not.

Anyway, where you see `complications' I see refreshing simplicity.

-Miles
-- 
97% of everything is grunge

Re: Suggestions for mode-line-format changes

[Kim F. Storm]

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

> kifer@cs.stonybrook.edu (Michael Kifer) writes:
> > I don't know.  I don't like programs that know better than I what I should
> > be doing.
> 
> I think the heuristic I mentioned would probably be right almost all of
> the time (and _all of the time_ for the overwhelmingly common case where
> you're not doing simultaneous ediffs on the same file).

For me, it would work 100%.

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

Re: Suggestions for mode-line-format changes

[Kim F. Storm]

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

> Michael Kifer <kifer@cs.sunysb.edu> writes:
> >     Miles> I'd like it so that command in one of the source buffers
> >     Miles> simply mapped to the control buffer, which would stay
> >     Miles> hidden (even when `in use').
> > 
> > This info is present, since each buffer has a local var that contain the
> > list of control buffers of the ediff sessions related to it.
> 
> Ok; so perhaps the following would suffice:
> 
>   * A minor-mode that just contains a keymap full of appropriate
>     commands that redirect to the first ediff control-buffer in the list
>     (perhaps conditionalized on buffer-read-only like in diff-mode).
>     It looks like `ediff-prepare-buffer-hook' could be used to turn on
>     the minor mode in each source buffer.

For my normal ediff usage, the 'read-only' is command mode idea is
really quite interesting.

I use CVSREAD=y, i.e. my cvs files any normally checked out read-only.
Only when I do "C-x v v", the file becomes writeable.

Now, if I want to merge a change from one branch of the CVS tree, I first
commit the changes on one branch, leaving the buffer containing the modified
file read-only.

I then open the file from the other branch and do C-x v v to make that revision
writeable.

This means that in one window I have the file _with modifications_
that I need to merge from (the source buffer) which is read-only, and
in another window I have the file _without modifications_ which need
to be patched (the target buffer) which is writeable.

Now, with Miles' idea, I can freely edit the writeable target buffer
using all my usual emacs commands without worrying about ediff, and to
emit ediff commands, I simply switch to the read-only source buffer
where the minor-mode keymap gives instant access to the ediff commands.

Since this is how I use ediff 99% of the time, I'd love a simplified
GUI like that!

And although I've used ediff for years (and love it for the things it
can do) I have never used multiple ediff sessions.

> 
>   * An ediff window-configuration function that always keeps the
>     control-window hidden.
> 

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

Re: Suggestions for mode-line-format changes

[Alan Shutko]

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

> I guess it could always be done using a "tool-tip" like approach, ie.
> by displaying the information in a separate "global-mode-frame".

So, where does it go when the user is on a text terminal?  Does it
just disappear?

I don't really like this approach for the default.  As options, yes.
(And add in the option to put it in the terminal status line or the
titlebar.)  But I'm not convinced that requiring the user to decide
where a little floating frame will do the least damage (ie, cover up
things that are less likely to be important) is a good thing.

-- 
Alan Shutko <ats@acm.org> - In a variety of flavors!
Beware of people that put numbers after their names.

Re: Suggestions for mode-line-format changes

[Alan Shutko]

huug <huug.at.gmane@xs4all.nl> writes:

> Eheh. And if you're not using a text console, you usually have better
> options then global-mode-line, I think. DockApplets like wmCalClock,
> WMMail and wmcpuload you can see on all your Workspaces, not just the
> one Emacs uses.

Huh?  You don't have an Emacs window on every workspace?  Actually, I
got rid of all my apps in favor of the mode-line, since it takes up
less space.

> Speaking of Workspaces, I think there's a bug here: no matter which
> one I start Emacs from, it creates its frame in #1.  Or would that
> be WindowMakers fault?

I'm fairly sure that it's Windowmaker's fault....

-- 
Alan Shutko <ats@acm.org> - In a variety of flavors!
Wisdom is rarely found on the best-seller list.

Re: Suggestions for mode-line-format changes

[Glenn Morris]

huug wrote:

> Speaking of Workspaces, I think there's a bug here: no matter which
> one I start Emacs from, it creates its frame in #1.  Or would that be
> WindowMakers fault?

It doesn't do that for me - Emacs appears in the workspace where I started
it. Maybe you have told WindowMaker to always start Emacs in workspace 1?
To check:
Right-click on the WM title bar of an Emacs window, choose Attributes, then
"Icon and Initial Workspace" from the menu. Is the "Initial Workspace" item
set to "Nowhere in particular"?

And just to add my tuppence worth to the whole "mode-line" business, I have
put the time and date in a mode-line tooltip via display-time-string-forms,
which saves space in the mode-line and stops me clock-watching, as the
clock only appears when I want it to. No use for console mode of course
though, as has been said.

Re: Suggestions for mode-line-format changes

[Kim F. Storm]

Kenichi Handa <handa@etl.go.jp> writes:

> In article <5xk7mlfsvf.fsf@kfs2.cua.dk>, storm@cua.dk (Kim F. Storm) writes:
> > Now that the mode-line-position information has been moved
> > from the end of the mode line, and vc-mode is moved there too,
> > the space between the buffer name and the mode-line-modes
> > has become pretty crowded.
> 
> > Now, if you enable display-time and display-battery,
> > which adds time and battery status, e.g. 15:57 [95%],
> > to that part of the mode line as well, it's a total mess.
> 
> I'd like to display such global information not in the mode
> line but, for instance, at the right end of menu bar, or
> tool bar if they exist.

I had the same thought, but didn't have any clue how to do it.

Actually, when I was working on the MS-DOG port a long time ago
I added the ability to display the time at the far right of
the menu bar.  It worked by writing directly to the relevant
addresses in VGA memory, so it's no wonder that code has been
removed since then :-)

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

Re: Suggestions for mode-line-format changes

[Alan Shutko]

Kenichi Handa <handa@etl.go.jp> writes:

> I'd like to display such global information not in the mode
> line but, for instance, at the right end of menu bar, or
> tool bar if they exist.  

No.  This information is important to the user (otherwise the user
would not have turned it on).  Putting it at the end of anything, be
it the mode-line, the menu bar, or the tool bar, will sometimes lose
this information if the toolbar or menubar is too long (which often,
it is).


-- 
Alan Shutko <ats@acm.org> - In a variety of flavors!
Who the hell cares where Carmen Sandiego is?

Re: Suggestions for mode-line-format changes

[Kenichi Handa]

In article <87znvd1qkr.fsf@wesley.springies.com>, Alan Shutko <ats@acm.org> writes:
> Kenichi Handa <handa@etl.go.jp> writes:
>>  I'd like to display such global information not in the mode
>>  line but, for instance, at the right end of menu bar, or
>>  tool bar if they exist.  

> No.  This information is important to the user (otherwise the user
> would not have turned it on).  Putting it at the end of anything, be
> it the mode-line, the menu bar, or the tool bar, will sometimes lose
> this information if the toolbar or menubar is too long (which often,
> it is).

I mean "... at the right end of menu bar ... overriding the
other data".  So, if that is implemented, we don't loose
that information.  It may be better that the hidden part
appears (by hiding display-time-string) when one moves mouse
to the area in the menu bar where normal menus are
displayed.

---
Ken'ichi HANDA
handa@etl.go.jp

Re: Suggestions for mode-line-format changes

[Stefan Monnier]

> I mean "... at the right end of menu bar ... overriding the
> other data".  So, if that is implemented, we don't loose
> that information.  It may be better that the hidden part
> appears (by hiding display-time-string) when one moves mouse
> to the area in the menu bar where normal menus are
> displayed.

I kind of like the idea of putting global info somewhere else than the
modeline, but I can't resist pointing out that Motif's menubar has the
`Help' menu stuck all the way to the right hand side (and I actually
like it and find that the Lucid toolkit should be improved to do the
same).  Hiding it while the mouse is away might not be such a good idea.

	
	Stefan

Re: Suggestions for mode-line-format changes

[Kenichi Handa]

In article <200208251823.g7PINIZ21246@rum.cs.yale.edu>, "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> I kind of like the idea of putting global info somewhere else than the
> modeline, but I can't resist pointing out that Motif's menubar has the
> `Help' menu stuck all the way to the right hand side (and I actually
> like it and find that the Lucid toolkit should be improved to do the
> same).  Hiding it while the mouse is away might not be such a good idea.

Oops.  In such a situation, I agree.

By the way, what happens if there are more menus than what
fit in a line?  Does `help' menu override the others?

---
Ken'ichi HANDA
handa@etl.go.jp

Re: Suggestions for mode-line-format changes

[Stefan Monnier]

> In article <200208251823.g7PINIZ21246@rum.cs.yale.edu>, "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> > I kind of like the idea of putting global info somewhere else than the
> > modeline, but I can't resist pointing out that Motif's menubar has the
> > `Help' menu stuck all the way to the right hand side (and I actually
> > like it and find that the Lucid toolkit should be improved to do the
> > same).  Hiding it while the mouse is away might not be such a good idea.
> 
> Oops.  In such a situation, I agree.
> 
> By the way, what happens if there are more menus than what
> fit in a line?  Does `help' menu override the others?

It spreads over more lines ;-)


	Stefan

Re: Suggestions for mode-line-format changes

[Alan Shutko]

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

> My suggestion is to move the global-mode-string to the
> end of the mode line; the cost is that the time and
> battery status isn't always shown (especially in
> partial width windows).

I've just updated to your changes, and I really don't like them.  In
one file, it took me from having everything in the modeline displaying
on an 80-character-wide window to losing half of my battery status.

People put stuff in global-mode-string because they always want to
see them.  They don't want to lose it because the mode-string is too
long!  

Personally, I think that the global-mode-string information is more
important to me than the modes, and this new change is exactly
opposite my priorities.  I think that most people would probably agree
with me.  Can we have a survey of some sort to decide whether to keep
this change?  (Right now, I yanked the entire mode-line setup out of
the old bindings.el, but that means I lose out on actual
improvements.)

-- 
Alan Shutko <ats@acm.org> - In a variety of flavors!
Hell, I don't know. Just ask me, I'll tell ya.

Re: Suggestions for mode-line-format changes

[Bill White]

On Fri Aug 23 2002 at 11:33, Alan Shutko <ats@acm.org> said:

> Personally, I think that the global-mode-string information is more
> important to me than the modes, and this new change is exactly
> opposite my priorities.  I think that most people would probably
> agree with me.  Can we have a survey of some sort to decide whether
> to keep this change?  (Right now, I yanked the entire mode-line
> setup out of the old bindings.el, but that means I lose out on
> actual improvements.)

I'm with Alan.  Since time immemorial (or, like, 1992) I've looked at
one place on the screen to get the time and date.  Now it's way over
there somewhere, if I'm lucky and haven't done C-x 3.

bw
-- 
Bill White                                               Office: 5N-X30
Documentation Programmer                      Phone: 217-398-0700 x 234
Wolfram Research                                      Fax: 217-398-0747
http://members.wri.com/billw        Office hours: 4am-noon Mon-Wed, Fri

Re: Suggestions for mode-line-format changes

[Kim F. Storm]

Bill White <billw@wolfram.com> writes:

> On Fri Aug 23 2002 at 11:33, Alan Shutko <ats@acm.org> said:
> 
> > Personally, I think that the global-mode-string information is more
> > important to me than the modes, and this new change is exactly
> > opposite my priorities.  I think that most people would probably
> > agree with me.

I guess most users will agree that knowing the time is
important around lunch time and near the end of the day :-)

> >  Can we have a survey of some sort to decide whether
> > to keep this change?  (Right now, I yanked the entire mode-line
> > setup out of the old bindings.el, but that means I lose out on
> > actual improvements.)
> 
> I'm with Alan.  Since time immemorial (or, like, 1992) I've looked at
> one place on the screen to get the time and date.  Now it's way over
> there somewhere, if I'm lucky and haven't done C-x 3.

Well for many years, I've looked near the end of the mode line for
the line and column number ... and they just moved too.

If they had sayed put, this would never have become an issue :-)

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

Re: Suggestions for mode-line-format changes

[Alan Shutko]

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

> I guess most users will agree that knowing the time is
> important around lunch time and near the end of the day :-)

It's also mail, battery status, and upcoming appointments for me.
Some packages I don't personally use which seem to use
global-mode-string include timeclock and viper.

> Well for many years, I've looked near the end of the mode line for
> the line and column number ... and they just moved too.
>
> If they had sayed put, this would never have become an issue :-)

If that's causing this many problems, maybe they should be moved
back, and we continue with the plans to allow customize to do
mode-line-format things.

I'm not sure what the best default for the mode-line is, but I'm not
sure we're improving it for the common case....

-- 
Alan Shutko <ats@acm.org> - In a variety of flavors!
Auditorium: Derived from 'audio' (to hear) and 'taurus' (bull).

Re: Suggestions for mode-line-format changes

[Eli Zaretskii]

On Sun, 25 Aug 2002, Alan Shutko wrote:

> storm@cua.dk (Kim F. Storm) writes:
> 
> > I guess most users will agree that knowing the time is
> > important around lunch time and near the end of the day :-)
> 
> It's also mail, battery status, and upcoming appointments for me.
> Some packages I don't personally use which seem to use
> global-mode-string include timeclock and viper.

How about making the mode line taller when the info it should display 
exceeds some threshold?  (Yes, on a tty that would mean the mode line 
will use two screen lines.)

Re: Suggestions for mode-line-format changes

[Miles Bader]

Eli Zaretskii <eliz@is.elta.co.il> writes:
> How about making the mode line taller when the info it should display 
> exceeds some threshold?  (Yes, on a tty that would mean the mode line 
> will use two screen lines.)

Given that the overflow is usually much less that a line's worth of
data, that would be a pretty big cost, unless the threshold were so
large that it would rarely be crossed (and imagine if the mode-lines for
all of your windows were two line; I think most people would prefer
truncate...)

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

Re: Suggestions for mode-line-format changes

[Miles Bader]

huug <huug.at.gmane@xs4all.nl> writes:
> And no, I'm not against changing things, but changes should be well
> thought out and the current user base ought to be able to retain the
> old behaviour with one custom setting (mentioned in NEWS).

If there are specific things you dislike, you should name them
explicitly.

Most changes to the mode-line seem to have been fairly minor, so it
hardly seems to be worth the trouble to add options to revert them
(since a user who _really_ objects can always define their own mode-line
format).  Of course, some are more major, e.g. the recent (and IMHO bad)
change to the location of line-numbers.

-Miles
-- 
Occam's razor split hairs so well, I bought the whole argument!

Re: Suggestions for mode-line-format changes

[Alan Shutko]

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

> Of course, some are more major, e.g. the recent (and IMHO bad)
> change to the location of line-numbers.

If we're keeping a list, another major change is the move to
global-mode-string.

-- 
Alan Shutko <ats@acm.org> - In a variety of flavors!
DOS 6.0: Bug City !

Re: Suggestions for mode-line-format changes

[Kim F. Storm]

Alan Shutko <ats@acm.org> writes:

> Miles Bader <miles@lsi.nec.co.jp> writes:
> 
> > Of course, some are more major, e.g. the recent (and IMHO bad)
> > change to the location of line-numbers.
> 
> If we're keeping a list, another major change is the move to
> global-mode-string.

As I've said before, my only reason for moving the global-mode-string
to the end of the string was the [IMO unnecessary] move of the line
numbers to the middle of the mode-line [which then became totally
over-crowded].

I'm all in favour of swapping them back to where they used to live!

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

Re: Suggestions for mode-line-format changes

[Kim F. Storm]

Alan Shutko <ats@acm.org> writes:

> storm@cua.dk (Kim F. Storm) writes:
> 
> > I guess most users will agree that knowing the time is
> > important around lunch time and near the end of the day :-)
> 
> It's also mail, battery status, and upcoming appointments for me.
> Some packages I don't personally use which seem to use
> global-mode-string include timeclock and viper.

IMO, showing the global-mode-string only once makes sense.
Having it in every window seems to be overkill.

So what about making the global-mode-string appear to the right in the
echo area when it is not in use for other purposes?

That (usually) empty line at the bottom of your screen could easily
show the time and battery status without too much eye strain...


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

Re: Suggestions for mode-line-format changes

[Alan Shutko]

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

> So what about making the global-mode-string appear to the right in the
> echo area when it is not in use for other purposes?

That might be nice.  I think I like it.  That would also let it
expand to the full width of the echo area when needed, without
bashing things off the mode-line as it used to do.

-- 
Alan Shutko <ats@acm.org> - In a variety of flavors!
Sits he on ever so high a throne, a man still sits on his bottom.

Re: Suggestions for mode-line-format changes

[Richard Stallman]

    So what about making the global-mode-string appear to the right in the
    echo area when it is not in use for other purposes?

I had the same idea this morning.  I think it would be good to try it
and see how well it goes.  Do you want to try it?

Re: Suggestions for mode-line-format changes

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     So what about making the global-mode-string appear to the right in the
>     echo area when it is not in use for other purposes?
> 
> I had the same idea this morning.  I think it would be good to try it
> and see how well it goes.  Do you want to try it?

Yes I can try it [if I can find the time].

Any ideas/pointers to how one can easily right-align text in a
(mini-buffer) window?

It seems a bit difficult at present...


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

Re: Suggestions for mode-line-format changes

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> Any ideas/pointers to how one can easily right-align text in a
> (mini-buffer) window?

Note that it's not really the mini-buffer most of the time, but rather
the echo-area (they are very different).

-Miles
-- 
"1971 pickup truck; will trade for guns"

Re: Suggestions for mode-line-format changes

[Kim F. Storm]

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

> storm@cua.dk (Kim F. Storm) writes:
> > Any ideas/pointers to how one can easily right-align text in a
> > (mini-buffer) window?
> 
> Note that it's not really the mini-buffer most of the time, but rather
> the echo-area (they are very different).
> 

Well, looking at the code the distinction is less clear IMO...

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

Re: Suggestions for mode-line-format changes

[Richard Stallman]

    Any ideas/pointers to how one can easily right-align text in a
    (mini-buffer) window?

You could calculate its width, subtract that from the total frame width,
and indent that much.

As Miles reminded us, this would be a kind of echo area
display--nothing to do with the minibuffer.  When the minibuffer is
active, this text will not appear.

The minibuffer is displayed as an ordinary buffer, displayed in a
buffer, so there is no special code for displaying it.  There is
special code for displaying the echo area.

Re: Suggestions for mode-line-format changes

[Mario Lang]

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

> Bill White <billw@wolfram.com> writes:
>
>> On Fri Aug 23 2002 at 11:33, Alan Shutko <ats@acm.org> said:
>> 
>> > Personally, I think that the global-mode-string information is more
>> > important to me than the modes, and this new change is exactly
>> > opposite my priorities.  I think that most people would probably
>> > agree with me.
>
> I guess most users will agree that knowing the time is
> important around lunch time and near the end of the day :-)
>
erc-track.el uses the global-mode-string to
indicate if a channel buffer not currently visible
had activity.  It is quite important for
this feature to be visible, and not scrolled out on the right side.

I agree that time isn't that important, but there are other things which can
be put into global-mode-string.  I dont think
it should be changed from it's current location.

OTOH, I always wanted something like global-mode-string
which only occurs once in a frame.  Currently, global-mode-string
is displayed as many times as windows are displayed in the current frame.
This is waste of space for most things using global-mode-string
(like time and the mail icon).

If we could come up with an equivalent which is only displayed
at one position in the frame, I'd like that.
(e.g. on the right side of the menu, or there somewhere).

P.S.: To be worthwhile, this feature would
need to work in X and -nw.


-- 
CYa,
  Mario

Re: Suggestions for mode-line-format changes

[Kim F. Storm]

Mario Lang <mlang@delysid.org> writes:

> erc-track.el uses the global-mode-string to
> indicate if a channel buffer not currently visible
> had activity.  It is quite important for
> this feature to be visible, and not scrolled out on the right side.
> 
> I agree that time isn't that important, but there are other things which can
> be put into global-mode-string.  I dont think
> it should be changed from it's current location.

There really seems to be different levels of importance of the things
people put into global-mode-string - some of which should be "very
visible" (e.g. battery status), some which should be "normally
visible" (e.g new mail, output available, important mode state), and
some which is just "nice to have" (e.g. time of day and system load).

Consequently, putting everything in a "global" state variable will
definitely not work well for all users...

Kai's idea of a fully configurable mode line format sounds nice, but
it will not work if we can only control where "global-mode-string" is
displayed in the mode-line; we need to be able to control the position
of each of the [current] elements of global-mode-string.

Maybe we could change the interpretation of global-mode-string [as the
last element in mode-line-format] in formatting the mode-line, so that
only the elements of global-mode-string which have not been
shown already are displayed for global-mode-string.

This could be done by maintaining a temporary list of the symbols used
so far to format the mode line and skip those symbols which have
already been displayed.  The means that you can insert
battery-mode-line-string explicitly in mode-line-format and not worry
about it being present in global-mode-string as well.


> 
> OTOH, I always wanted something like global-mode-string
> which only occurs once in a frame.  Currently, global-mode-string
> is displayed as many times as windows are displayed in the current frame.
> This is waste of space for most things using global-mode-string
> (like time and the mail icon).
> 
> If we could come up with an equivalent which is only displayed
> at one position in the frame, I'd like that.
> (e.g. on the right side of the menu, or there somewhere).
> 
> P.S.: To be worthwhile, this feature would
> need to work in X and -nw.

Displaying it in the (unused) echo area should work on all platform if
done correctly...

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

Re: Suggestions for mode-line-format changes

[Richard Stallman]

    erc-track.el uses the global-mode-string to
    indicate if a channel buffer not currently visible
    had activity.

Why use global-mode-string for this?  That doesn't seem
like the right method to use.  Why not put it in something
buffer-local?

Re: Suggestions for mode-line-format changes

[Kai Großjohann]

Alan Shutko <ats@acm.org> writes:

> Personally, I think that the global-mode-string information is more
> important to me than the modes, and this new change is exactly
> opposite my priorities.  I think that most people would probably agree
> with me.  Can we have a survey of some sort to decide whether to keep
> this change?  (Right now, I yanked the entire mode-line setup out of
> the old bindings.el, but that means I lose out on actual
> improvements.)

If it wasn't for the propertized strings in mode-line-format, it
would actually be easy for users to sort mode-line-format the way
they like: they just rearrange the existing elements the way they
like.

What do you think about making little variables mode-line-dash and
mode-line-space for them?

What do you think about doing a custom type for mode-line-format?  It
could be a list of variables whose names match the regexp "mode-line".

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: Suggestions for mode-line-format changes

[Richard Stallman]

    If it wasn't for the propertized strings in mode-line-format, it
    would actually be easy for users to sort mode-line-format the way
    they like: they just rearrange the existing elements the way they
    like.

    What do you think about making little variables mode-line-dash and
    mode-line-space for them?

That is a good idea--simple, painless, and probably useful.
Please do it.

    What do you think about doing a custom type for mode-line-format?  It
    could be a list of variables whose names match the regexp "mode-line".

That seems like a good idea too.  The custom type could be a series of
elements, each chosen from the set of suitable symbol names.

Re: Suggestions for mode-line-format changes

[Richard Stallman]

    Personally, I think that the global-mode-string information is more
    important to me than the modes, and this new change is exactly
    opposite my priorities.  I think that most people would probably agree
    with me.  Can we have a survey of some sort to decide whether to keep
    this change?

This seems like the right sort of question for a poll.