xdisaster

xdisaster

[Sean Sieger]

I run Emacs 23.0.0.1 in an xterm on Ubuntu 6.10.  I was just now
reading X manpages in M-x shell (for the first time) trying to figure
out why CVS AUCTeX doesn't see TeX Live 2007, but now I get:

matilda@bdfpj71:~$ man man
Reformatting man(1), please wait...
WARNING: terminal is not fully functional
-  (press RETURN)

Um, I want to twist this notebook of mine into four pieces (I've been
stuggling with this X problem for a week), what gives??

Re: xdisaster

[David Hansen]

On Wed, 11 Apr 2007 21:56:08 -0400 Sean Sieger wrote:

> I run Emacs 23.0.0.1 in an xterm on Ubuntu 6.10.  I was just now
> reading X manpages in M-x shell (for the first time) trying to figure
> out why CVS AUCTeX doesn't see TeX Live 2007, but now I get:
>
> matilda@bdfpj71:~$ man man
> Reformatting man(1), please wait...
> WARNING: terminal is not fully functional
> -  (press RETURN)
>
> Um, I want to twist this notebook of mine into four pieces (I've been
> stuggling with this X problem for a week), what gives??

Use M-x man or M-x woman or run `man' from an eshell prompt.

David

Re: xdisaster

[Kai Grossjohann]

David has explained what to do, I would like to explain why Emacs
behaves like this.

After M-x shell RET you are NOT in a terminal-like buffer.  (Use M-x
term RET for that.)  The advantage of a *shell* buffer is that you can
move around in it using the normal Emacs motion commands, you can copy
text from it, you can edit the text in it, and so on.

Besides the options mentioned by David, another one is to set the
environment variable $PAGER to cat.  Then the complete man page will be
printed into the *shell* buffer, for your perusal using normal Emacs
motion commands.

In your shell init files you can examine the environment variable
$TERM to see whether you are in shell-mode in Emacs, if you would like
to set $PAGER differently for this case.

Kai

Sean Sieger <sean.sieger@gmail.com> writes:

> I run Emacs 23.0.0.1 in an xterm on Ubuntu 6.10.  I was just now
> reading X manpages in M-x shell (for the first time) trying to figure
> out why CVS AUCTeX doesn't see TeX Live 2007, but now I get:
>
> matilda@bdfpj71:~$ man man
> Reformatting man(1), please wait...
> WARNING: terminal is not fully functional
> -  (press RETURN)
>
> Um, I want to twist this notebook of mine into four pieces (I've been
> stuggling with this X problem for a week), what gives??

Re: xdisaster

[Tim X]

Sean Sieger <sean.sieger@gmail.com> writes:

> I run Emacs 23.0.0.1 in an xterm on Ubuntu 6.10.  I was just now
> reading X manpages in M-x shell (for the first time) trying to figure
> out why CVS AUCTeX doesn't see TeX Live 2007, but now I get:
>
> matilda@bdfpj71:~$ man man
> Reformatting man(1), please wait...
> WARNING: terminal is not fully functional
> -  (press RETURN)
>
> Um, I want to twist this notebook of mine into four pieces (I've been
> stuggling with this X problem for a week), what gives??
>

Partially a guess. M-x shell gives you a 'dumb' terminal which does not support
the terminal addressing features required by man. M-x shell is for very simple
shell commands that do not require significant formatting of output. 

To get a fully functional terminal within emacs, use M-x term. BUT....

in emacs, to read man pages, use either M-x man or M-x woman. Both have
slightly different features. I find woman great for longer and more in-depth
man reading sessions, but M-x man is great when I just want to check something
like command line switches etc. 

HTH

Tim

-- 
tcross (at) rapttech dot com dot au

Re: xdisaster

[Sean Sieger]

Tim X <timx@nospam.dev.null> writes:

   in emacs, to read man pages, use either M-x man or M-x woman. Both
   have slightly different features. I find woman great for longer and
   more in-depth man reading sessions, but M-x man is great when I
   just want to check something like command line switches etc.

Thank you Tim.  M-x woman The thing that bugs me about M-x woman is
that it starts another instance of emacs; is there a way to prevent
this?

Re: xdisaster

[Kai Grossjohann]

Sean Sieger <sean.sieger@gmail.com> writes:

> Thank you Tim.  M-x woman The thing that bugs me about M-x woman is
> that it starts another instance of emacs; is there a way to prevent
> this?

It opens another frame.  (setq woman-frame nil) should fix this.

Kai

Re: xdisaster

[Sean Sieger]

Kai Grossjohann <kai@emptydomain.de> writes:

   Sean Sieger <sean.sieger@gmail.com> writes:

   > Thank you Tim.  M-x woman The thing that bugs me about M-x woman is
   > that it starts another instance of emacs; is there a way to prevent
   > this?

   It opens another frame.  (setq woman-frame nil) should fix this.

In Emacs 23.0.0.1, at least,

(setq woman-use-own-frame nil)

uh-huh, thank you for getting me started with reading the WoMan
manual, Kai--I'll get through it in short order.

I love living in Emacs.

Re: xdisaster

[Tim X]

Sean Sieger <sean.sieger@gmail.com> writes:

> Tim X <timx@nospam.dev.null> writes:
>
>    in emacs, to read man pages, use either M-x man or M-x woman. Both
>    have slightly different features. I find woman great for longer and
>    more in-depth man reading sessions, but M-x man is great when I
>    just want to check something like command line switches etc.
>
> Thank you Tim.  M-x woman The thing that bugs me about M-x woman is
> that it starts another instance of emacs; is there a way to prevent
> this?
>

Woman doesn't start another 'instance' of emacs. It will open up in its own
frame when running under X. You can change this behavior by setting the
variable woman-use-own-frame to nil. (Note that under emacs terminology, a
'frame' is similar to what is often referred to as a window by other systems). 

Either run woman (to make sure it has been loaded) and then do

M-x customize-group <RET> woman <RET> and find the appropriate entry (I believe
its under the subgroup woman-interface). Alternatively, just a 

(setq woman-use-own-frame nil)

in your .emacs will probably also work (though I'd highly recommend using the customize
interface). 

Tim

,----[ C-h v woman-use-own-frame RET ]
| woman-use-own-frame is a variable defined in `woman.el'.
| Its value is t
| 
| 
| Documentation:
| *If non-nil then use a dedicated frame for displaying WoMan windows.
| Only useful when run on a graphic display such as X or MS-Windows.
| 
| You can customize this variable.
`----


-- 
tcross (at) rapttech dot com dot au

Re: xdisaster

[Matthew Flaschen]

Tim X wrote:
> To get a fully functional terminal within emacs, use M-x term. BUT....

Thanks.  I didn't know about that feature.

Matt Flaschen

Re: xdisaster

[Sean Sieger]

Tim X <timx@nospam.dev.null> writes:

   (though I'd highly recommend using the customize interface).

Why is that?

That bit of code bugs me at the bottom of my .emacs; maybe that's
because I don't know elisp, so that the little I write, I want to be
handwritten--`all mine'.

Re: xdisaster

[Tim X]

Sean Sieger <sean.sieger@gmail.com> writes:

> Tim X <timx@nospam.dev.null> writes:
>
>    (though I'd highly recommend using the customize interface).
>
> Why is that?
>
> That bit of code bugs me at the bottom of my .emacs; maybe that's
> because I don't know elisp, so that the little I write, I want to be
> handwritten--`all mine'.
>

A couple of reasons. 

There are/can be situations where just a simple (setq ....) doesn't work as you
would expect. The customize interface can be setup so that setting a value
through that interface actually causes specific elisp functions to execute that
correctly set things or change things in a consistent manner. 

I've also had situations where for some reason, (setq doesn't work and the
default value still takes precedence. However, as soon as I set it through
customize, it works as expected. 

Using customize is quick, avoids silly errors that take time to debug and
allows me to spend time on more rewarding activities. It also has the advantage
of presenting all the user customizable aspects of a package in a convenient
and consistent manner. Most of the time, I can start some new mode/package I'm
not familiar with and when I see it doesn't do something the way I'd like it
to, I simply do a M-x customize <ret> package and all the ways I can modify the
behavior are there in front of me. I don't have to go through manuals or code
listings to try and work out how I can change things. Instead of spending hours
working out how to do something like change an indent style for a programming
mode or stop some feature from using its own frame etc, I just follow the
options presented by customize. I don't need to know if the setting is a
symbol, a boolean, a sequence, etc. 

This is possibly just a personal matter of taste, but I prefer to
actually put any elisp writing towards new functionality rather than
just simply setting some default values to customize behavior. For me, writing
basic setq statements and simple lambdas for load hooks etc is far less
rewarding than trying to write something completely new using elisp. 

Tim

-- 
tcross (at) rapttech dot com dot au

Re: xdisaster

[Sean Sieger]

Tim X <timx@nospam.dev.null> writes:

   This is possibly just a personal matter of taste, but I prefer to
   actually put any elisp writing towards new functionality rather than
   just simply setting some default values to customize behavior. For
   me, writing basic setq statements and simple lambdas for load hooks
   etc is far less rewarding than trying to write something completely
   new using elisp.

This why I couldn't resist taking the opportunity to ask; I knew you'd
write an enlightening response.  Thank you, Tim.  Especially the simple
turn regarding functional elisp--I so need to get back to reading eintr
and learning elisp.

Re: xdisaster

[Stephen Berman]

On Sat, 14 Apr 2007 19:12:52 +1000 Tim X <timx@nospam.dev.null> wrote:

> Using customize is quick, avoids silly errors that take time to
> debug and allows me to spend time on more rewarding activities. It
> also has the advantage of presenting all the user customizable
> aspects of a package in a convenient and consistent manner. 

Moreover, (as with any code) using customize tests its correctness and
consistency, and may uncover bugs in the code; in particular, since
options set by the Custom interface are meant to be evaluated at the
end of the user's other initializations, by using that interface
rather than setting the options earlier in your init file, you may
find subtle ordering bugs the the Custom code.  This happened to me
several times recently, and the bug reports I submitted resulted in
quick fixes.

Steve Berman