headers
Kim F. Storm | 1 Jun 2002 02:12
Picon

Re: Emacs mode for GDB - 2 questions

Richard Stallman <rms <at> gnu.org> writes:

>     With a large array, if the top line was in the buffer it would scroll out of 
>     view. I would like to be able to enter the three digits (0,5,2 in this case)
>     into the header line.
> 
> That feature makes sense well enough, but as I said, it would
> be difficult to implement.

There are obvious alternative ways to accomplish the same effect
(e.g. click on the header-line and use the mini-buffer to enter the
numbers).  To me that seems like a more logical approach than editing
the numbers directly in the header line -- when and how do you then
determine what numbers to actually use -- and how do you change,
e.g. the 5 to 10? do you delete the 5 first and then enter 1 and 0
(giving 2 interrim data values in the middle field).

I'd definitely prefer to use the minibuffer for this kind of input.

> 
> But I have another idea for implementing it.  Suppose that line were
> actually a separate window, with its mode line disabled, showing just
> one line of some buffer.  That way you could indeed select it and edit
> it as usual.  You could make the parts that should not really be edited
> read-only.
> 
Such modeline-less windows may be useful for other purposes, so
we should try adding them to see what use people can find for them.

> This would require a new feature in the C code, but since it would
(Continue reading)

Permalink | Reply | 5 comments |
headers
Miles Bader | 1 Jun 2002 01:21
Picon
Gravatar

Re: Emacs mode for GDB - 2 questions

Richard Stallman <rms <at> gnu.org> writes:
> Suppose that every mode line (and every header line) were actually a
> separate window, and formatting of mode line elements was done by
> converting them into text in a buffer.  That would be elegant in some
> ways.  The usage of memory for this would be acceptable nowadays.
...
> What do people think?

I think it would be very cool, although the mode-line/header-line are
special cased to such an extent in the display engine that it makes me
wonder how many unseen gotchas there are.  Another cool think is that
this might make it easier to have multiple header-lines (or
mode-lines!), which I've sometimes wanted.

A related issue:  I've always thought it would be nice if emacs had some
way of `binding' windows together, so that, they could be treated as a
unit in some respects (i.e., other windows couldn't pop up between them,
and perhaps switching buffers using C-x C-b would switch the _whole_
group of bound windows instead of just the current leaf window).  I
would like it if the Gnus summary/article buffers were bound in this
way, for instance.  Promoting mode-lines and header-lines to real
windows might fit well with this sort of mechanism.

My vague thought was that since windows area already arranged in a tree,
that somehow non-leaf windows could be marked as the `root' of a set of
bound windows, and certain operations (switch-to-buffer?) would walk up
the tree and use such `bound roots' instead of the leaf window if it
found one.

Anyway, just a thought.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Miles Bader | 1 Jun 2002 01:43
Picon
Gravatar

Re: Emacs mode for GDB - 2 questions

storm <at> cua.dk (Kim F. Storm) writes:
> Such modeline-less windows may be useful for other purposes, so
> we should try adding them to see what use people can find for them.

They already exist -- just do (setq mode-line-format nil).
Works like a charm.

-Miles
--

-- 
80% of success is just showing up.  --Woody Allen
Permalink | Reply | 2 comments |
headers
Gerd Moellmann | 1 Jun 2002 12:14
Picon
Favicon

Re: A different color appears in the unused screen lines

Richard Stallman <rms <at> gnu.org> writes:

> When I put this in .emacs
> 
> (custom-set-faces
>   ;; custom-set-faces was added by Custom -- don't edit or cut/paste it!
>   ;; Your init file should contain only one such instance.
>  '(default ((t (:stipple nil :background "DarkSlateGray" :foreground "wheat" :inverse-video nil :box
nil :strike-through nil :overline nil :underline nil :slant normal :weight normal :height 135 :width
normal :family "adobe-courier")))))
> 
> the specified colors appear, but empty areas of the screen--those
> beyond the last character on the line or in the buffer--come out in a
> different color, a little lighter than DarkSlateGray.
> 
> I did M-x list-faces-display, and I saw that no face had a background
> equivalent to the color of those empty areas.
> 
> I tried substituting a couple of other background colors.  I tried
> "black" and "blue".  In those cases, the problem did not happen:
> the screen appeared black or blue down to the end.
> 
> Does anyone know where that color is coming from?  I tried to study
> the display code to figure it out but I can't find it.  I suspect that
> the cause has to do with what GC is specified when x_clear_end_of_line
> runs; does anyone know where that is specified?

I believe setting the background color of the default face sets the
frame's X window background color via frame parameters.  The function
x_clear_end_of_line uses XClearArea which doesn't use a GC; it clears
(Continue reading)

Permalink | Reply | 2 comments |
headers
Alan Shutko | 1 Jun 2002 18:42
Picon
Favicon

Re: Building emacs with and without X -- packaging question.

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

> If you mean that DOC doesn't include all the doc strings it should,
> then it's a bug that should be fixed.

No, it's related to this section from etc/PROBLEMS:

    * Self documentation messages are garbled.

    This means that the file `etc/DOC-...' doesn't properly correspond
    with the Emacs executable.  Redumping Emacs and then installing the
    corresponding pair of files should fix the problem.

I'm afraid I don't know how this section works, just that if you
recompile Emacs without X but use the DOC from the X version, the
messages are garbled.  The RH patches I looked at way back when
referenced a DOC and a DOC-X11, depending on how it was compiled
(iirc).

--

-- 
Alan Shutko <ats <at> acm.org> - In a variety of flavors!
My, how you've changed since I've changed.
Permalink | Reply | 49 comments |
headers
Eli Zaretskii | 1 Jun 2002 18:50
Picon

Re: Building emacs with and without X -- packaging question.

> Date: Sat, 01 Jun 2002 12:42:20 -0400
> From: Alan Shutko <ats <at> acm.org>
> 
> I'm afraid I don't know how this section works, just that if you
> recompile Emacs without X but use the DOC from the X version, the
> messages are garbled.

That's a clear sign of a bug, IMHO.  src/Makefile.in is supposed to be
set up so that all versions of Emacs get the same functions
documented.  That's why ${docdir} is not architecture dependent.
Permalink | Reply | 48 comments |
headers
Alex Schroeder | 1 Jun 2002 21:44

Re: Emacs mode for GDB - 2 questions

Miles Bader <miles <at> gnu.org> writes:

> storm <at> cua.dk (Kim F. Storm) writes:
>> Such modeline-less windows may be useful for other purposes, so
>> we should try adding them to see what use people can find for them.
>
> They already exist -- just do (setq mode-line-format nil).
> Works like a charm.

Too bad I cannot make it frame-local...  I'm trying to create new
frames without any extra stuff in them.  But the mode line is
buffer-local...

(set (make-variable-frame-local 'mode-line-format) nil)

Debugger entered--Lisp error: (error "Symbol mode-line-format may not be frame-local")
  make-variable-frame-local(mode-line-format)
  (set (make-variable-frame-local (quote mode-line-format)) nil)
  eval((set (make-variable-frame-local (quote mode-line-format)) nil))
  eval-last-sexp-1(nil)
  eval-last-sexp(nil)
  call-interactively(eval-last-sexp)

Alex.
Permalink | Reply | 1 comment |
headers
Nick Roberts | 1 Jun 2002 22:44

Re: Emacs mode for GDB - 2 questions

Eli Zaretskii writes:

 > From: storm <at> cua.dk
 ...
 > > Couldn't you get the input from the mini-buffer (using some command)
 > > and just show the entered values in the header line?  
 > 
 > Indeed.  For example, clicking on one of the numbers could prompt for
 > input.

I like this idea. I'll try to implement it.

Nick
Permalink | Reply | 0 comments |
headers
Richard Stallman | 1 Jun 2002 23:03
Picon
Picon

Re: Emacs 21.2 display bugs: variables: cursor-type; properties: display, before-string, after-string, invisible, intangible

Thanks for calling my attention to the problem.
Permalink | Reply | 0 comments |
headers
Richard Stallman | 1 Jun 2002 23:03
Picon
Picon

Beyond the fringe

In etc/TODO it says

    * Move fringe to be displayed between display margins and text area.

If this is done, we can call the display margins
"beyond the fringe".

;-).
Permalink | Reply | 0 comments |

Gmane