`b'

`b'

[Lars Magne Ingebrigtsen]

I forgot to mention -- 0.34 has a new command: `b'.  It dis*b*lays a
MIME part.  (Elegant mnemonic, huh?)  The prefix is the number.  Er.
The numeric prefix is the part number.

Hm.  I really should be asleep now.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Magne Ingebrigtsen

Re: `b'

[Jason R Mastaler]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

> Hm.  I really should be asleep now.

Now this is something I never thought I'd hear.  :-)

Re: `b'

[Simon Josefsson]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

> I forgot to mention -- 0.34 has a new command: `b'.  It dis*b*lays a
> MIME part.  (Elegant mnemonic, huh?)  The prefix is the number.  Er.
> The numeric prefix is the part number.

Pressing `2 b' in a article with several text/plain parts hides the
second part for me. It also doesn't change the cursor point, so when
I'm reading the first part, pressing `2 b' only toggles wether the
second part should be visible or not, it doesn't actually display the
second part.

Wouldn't it also be nice if I press `b' (no prefix), with the cursor
in the article buffer on a MIME-part, and it toggles wether it should
be displayed? Right now it toggles wether the first part should be
displayed, regardless of where the cursor is in the article.

Btw, displaying a message/rfc822 part leaves me in a new buffer with
the article, point at eob and in fundamental mode.

s

Re: `b'

[Kai Grossjohann]

>>>>> Simon Josefsson <jas@pdc.kth.se> writes:

  > Pressing `2 b' in a article with several text/plain parts hides
  > the second part for me. It also doesn't change the cursor point,
  > so when I'm reading the first part, pressing `2 b' only toggles
  > wether the second part should be visible or not, it doesn't
  > actually display the second part.

`4 2 b' is the same as hitting RET on the MIME part numbered 42.  RET
on an inline-able part toggles visibility, on a non-inline-able part
it starts the viewer.

  > Wouldn't it also be nice if I press `b' (no prefix), with the cursor
  > in the article buffer on a MIME-part, and it toggles wether it should
  > be displayed? Right now it toggles wether the first part should be
  > displayed, regardless of where the cursor is in the article.

Use RET.

  > Btw, displaying a message/rfc822 part leaves me in a new buffer
  > with the article, point at eob and in fundamental mode.

This bug was reported before, I think.

kai
-- 
I wonder why nobody don't like me,
or is it de fact dat I'm ugly? -- Harry Belafonte

Re: `b'

[Simon Josefsson]

Kai Grossjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

>   > Pressing `2 b' in a article with several text/plain parts hides
>   > the second part for me. It also doesn't change the cursor point,
>   > so when I'm reading the first part, pressing `2 b' only toggles
>   > wether the second part should be visible or not, it doesn't
>   > actually display the second part.
> 
> `4 2 b' is the same as hitting RET on the MIME part numbered 42.

Oh, I though it was supposed to display the part. :-)

Is there a way from the article buffer to jump to (and display) part
42 then?  Couldn't `b' do this?

Time for a *Article tree* buffer?

>   > Wouldn't it also be nice if I press `b' (no prefix), with the cursor
>   > in the article buffer on a MIME-part, and it toggles wether it should
>   > be displayed?
>
> Use RET.

Gives me a backtrace:

Signaling: (buffer-read-only #<buffer *Article*>)
  call-interactively(newline)
  widget-button-press(2256)
* call-interactively(widget-button-press)

/s

Re: `b'

[Lee Willis]

Simon Josefsson <jas@pdc.kth.se> writes:

> Is there a way from the article buffer to jump to (and display) part
> 42 then?  Couldn't `b' do this?
> 
> Time for a *Article tree* buffer?

I think hitting C-d on the article in the Summary buffer may give you
what you want here ...
{Or maybe not ...}

Lee.
-- 
I was doing object-oriented assembly at 1 year old ...  
For some reason my mom insists on calling it "Playing with blocks"

Re: `b'

[Kai Grossjohann]

>>>>> Simon Josefsson <jas@pdc.kth.se> writes:

  > Oh, I though it was supposed to display the part. :-)

Well, if it's displayed already, you don't need `b' :-)

  > Is there a way from the article buffer to jump to (and display) part
  > 42 then?  Couldn't `b' do this?

You can use TAB to move from button to button.  You can use `4 2 b' to
display the part # 42 (or toggle its visibility, if that part is
inline).

  > Time for a *Article tree* buffer?

Somebody suggested C-d already.

  > >   > Wouldn't it also be nice if I press `b' (no prefix), with the cursor
  > >   > in the article buffer on a MIME-part, and it toggles wether it should
  > >   > be displayed?
  > >
  > > Use RET.
  > 
  > Gives me a backtrace:

RET must be used when point is on a button.

kai
-- 
I wonder why nobody don't like me,
or is it de fact dat I'm ugly? -- Harry Belafonte

Re: `b'

[Hrvoje Niksic]

Kai Grossjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

> >>>>> Simon Josefsson <jas@pdc.kth.se> writes:
> 
>   > Oh, I though it was supposed to display the part. :-)
> 
> Well, if it's displayed already, you don't need `b' :-)

No, but Simon's point might be that the command should be named
gnus-article-toggle-part instead of ...-view-part.

>   > Is there a way from the article buffer to jump to (and display)
>   > part 42 then?  Couldn't `b' do this?
> 
> You can use TAB to move from button to button.

Well.  `41 TAB' would work if you were on the first button, otherwise
you'd have to subtract.  Also, it doesn't work from the Summary
buffer.  However, this doesn't distress me much because I don't see
any practical use for a command able to "display part 42".

>   > Time for a *Article tree* buffer?
> 
> Somebody suggested C-d already.

C-d is not well-designed in comparison to other MIME viewers out
there.  I've written about this before.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Speak softly and carry a +6 two-handed sword.

Re: `b'

[François Pinard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 488 bytes --]

Hrvoje Niksic <hniksic@srce.hr> writes:

> > Somebody suggested C-d already.

> C-d is not well-designed in comparison to other MIME viewers out
> there.  I've written about this before.

You surely wrote it many times, Hrvoje, but you never explained :-).

(Or I missed your explanation.  I'm a few hundred messages behind in Gnus.)

-- 
François Pinard                            mailto:pinard@iro.umontreal.ca
Join the free Translation Project!    http://www.iro.umontreal.ca/~pinard

Re: `b'

[Hrvoje Niksic]

François Pinard <pinard@IRO.UMontreal.CA> writes:

> Hrvoje Niksic <hniksic@srce.hr> writes:
> 
> > > Somebody suggested C-d already.
> 
> > C-d is not well-designed in comparison to other MIME viewers out
> > there.  I've written about this before.
> 
> You surely wrote it many times, Hrvoje, but you never explained :-).
> 
> (Or I missed your explanation.

You missed it.  In a true MIME-viewing mode, `o' should save only the
message body, one should be able to access the unhacked headers,
uuencoded messages should work just like they do with regular buttons, 
etc.

Also, C-d is already too overloaded -- it attempts to do all kinds of
things with the messages.  Adding tree-like MIME display looks like
one too much to me.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it."                                    -- Donald Knuth

Re: `b'

[Kai Grossjohann]

>>>>> Hrvoje Niksic <hniksic@srce.hr> writes:

  > Also, C-d is already too overloaded -- it attempts to do all kinds
  > of things with the messages.  Adding tree-like MIME display looks
  > like one too much to me.

I love C-d!  It lets me easily look at digests and multipart messages
and stuff -- very nifty!

Maybe it's a matter of taste?  Lars can't satisfy everybody, though he
tries real hard :-)

kai
-- 
Life is hard and then you die.

Re: `b'

[Hrvoje Niksic]

Kai Grossjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

> >>>>> Hrvoje Niksic <hniksic@srce.hr> writes:
> 
>   > Also, C-d is already too overloaded -- it attempts to do all kinds
>   > of things with the messages.  Adding tree-like MIME display looks
>   > like one too much to me.
> 
> I love C-d!  It lets me easily look at digests and multipart messages
> and stuff -- very nifty!
> 
> Maybe it's a matter of taste?  Lars can't satisfy everybody, though he
> tries real hard :-)

You must be somehow misunderstanding my words.  Yes, I like C-d, but I 
don't like its implementation for MIME.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
We are all just prisoners here of our own MAKEDEV.

Re: `b'

[Kai Grossjohann]

>>>>> Hrvoje Niksic <hniksic@srce.hr> writes:

  > You must be somehow misunderstanding my words.  Yes, I like C-d,
  > but I don't like its implementation for MIME.

Hm.  I haven't looked at the Lisp source, but I like what it does for
multipart MIME messages.

Are you saying you don't like what it does or are you saying you don't
like the Lisp source that does it?

kai
-- 
Life is hard and then you die.

Re: `b'

[Hrvoje Niksic]

Kai Grossjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

> Are you saying you don't like what it does or are you saying you
> don't like the Lisp source that does it?

Both.

For the former, I'd like for instance `o' to save the messages without 
the (bogus) headers.  I would also prefer headers not to be inherited
and shown.

For the latter, I'd like the code to use the existing Gnus MIME engine 
(the mm-* stuff), so that it works for uuencoded files, etc.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
- Now what did we learn from this?
- I learned what my liver looks like!

Re: `b'

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> For the former, I'd like for instance `o' to save the messages without 
> the (bogus) headers.  I would also prefer headers not to be inherited
> and shown.

I don't think nndoc should handle MIME articles the same way that mm
does.  What's the point in having two commands if both do the same?

I think `C-d' does something quite reasonable with MIME multipart
articles.  If someone sends me a huge MIME multipart/mixed, and I wish
to respond to only one text part in it, `C-d', select part and `F'
works perfectly.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: `b'

[François Pinard]

Hrvoje Niksic <hniksic@srce.hr> écrit:

> > > C-d is not well-designed in comparison to other MIME viewers out
> > > there.  I've written about this before.

> Also, C-d is already too overloaded -- it attempts to do all kinds of
> things with the messages.  Adding tree-like MIME display looks like
> one too much to me.

Is that really an argument?  If `C-d' does not have a meaning for MIME
messages, I see no problem that it gets one.  The `nndoc' concept, per
definition, should be able to do many intelligent things, not only one.

> In a true MIME-viewing mode, `o' should save only the message body, one
> should be able to access the unhacked headers, uuencoded messages should
> work just like they do with regular buttons, etc.  [...]  I'd like for
> instance `o' to save the messages without the (bogus) headers.  I would
> also prefer headers not to be inherited and shown.

`C-d' does not attempt to trigger a MIME-viewing mode.  It only generates
full, complete, valid messages representing useful subtrees of the MIME tree
for a single original message.  You then use any command able to manoeuvre
_full_ messages on subtrees.  Here, `o' does not get specially overloaded,
and has no reason to be.  It means what it always meant for full messages.

If you imply that `C-d' is meant for other things it was really meant for,
then of course, it is likely that it was not well designed to do them.

> For the latter, I'd like the code to use the existing Gnus MIME engine
> (the mm-* stuff), so that it works for uuencoded files, etc.

I think, I may be biased (:-), that `C-d' does its job well, and even, that
the code is not so badly written.  Maybe it could do better now using `mm-*'
stuff?  Such `mm-*' did not exist at the time `C-d' became able to split
MIME parts, and `C-d' has most probably not been reevaluated since then.
You say that using `mm-*' will give us `uuencoded' parts?  Anything else?

-- 
François Pinard                            mailto:pinard@iro.umontreal.ca
Join the free Translation Project!    http://www.iro.umontreal.ca/~pinard

Re: `b'

[Lars Magne Ingebrigtsen]

François Pinard <pinard@iro.umontreal.ca> writes:

> I think, I may be biased (:-), that `C-d' does its job well, and even, that
> the code is not so badly written.  Maybe it could do better now using `mm-*'
> stuff?  Such `mm-*' did not exist at the time `C-d' became able to split
> MIME parts, and `C-d' has most probably not been reevaluated since then.
> You say that using `mm-*' will give us `uuencoded' parts?  Anything else?

I don't think so.  I think the `C-d' on MIME multiparts works very
well, and I don't think it is productive to make the nndoc interface
more un-Gnusey. 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: `b'

[Hrvoje Niksic]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> François Pinard <pinard@iro.umontreal.ca> writes:
> 
> > I think, I may be biased (:-), that `C-d' does its job well, and even, that
> > the code is not so badly written.  Maybe it could do better now using `mm-*'
> > stuff?  Such `mm-*' did not exist at the time `C-d' became able to split
> > MIME parts, and `C-d' has most probably not been reevaluated since then.
> > You say that using `mm-*' will give us `uuencoded' parts?  Anything else?
> 
> I don't think so.  I think the `C-d' on MIME multiparts works very
> well, and I don't think it is productive to make the nndoc interface
> more un-Gnusey.

This part of Francois' message talked about the implementation of
MIMEoid C-d, not its interface.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Unspeakable horrors from outer space paralyze the living and
resurrect the dead!

Re: `b'

[Hrvoje Niksic]

François Pinard <pinard@iro.umontreal.ca> writes:

> > In a true MIME-viewing mode, `o' should save only the message
> > body, one should be able to access the unhacked headers, uuencoded
> > messages should work just like they do with regular buttons, etc.
> > [...]  I'd like for instance `o' to save the messages without the
> > (bogus) headers.  I would also prefer headers not to be inherited
> > and shown.
> 
> `C-d' does not attempt to trigger a MIME-viewing mode.

I know.  I would prefer if it did trigger a Summary-based MIME viewing 
mode, but I've obviously lost that battle.

> > For the latter, I'd like the code to use the existing Gnus MIME
> > engine (the mm-* stuff), so that it works for uuencoded files,
> > etc.
> 
> I think, I may be biased (:-), that `C-d' does its job well, and
> even, that the code is not so badly written.  Maybe it could do
> better now using `mm-*' stuff?  Such `mm-*' did not exist at the
> time `C-d' became able to split MIME parts, and `C-d' has most
> probably not been reevaluated since then.  You say that using `mm-*'
> will give us `uuencoded' parts?  Anything else?

mm- code might be more correct about various other MIME thingies that
come into play over time.  And the code is already conceived as a
library.  Long-term, I think it would simply make more sense to use it 
rather than the home-grown stuff.  It's only a wish, though.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Nostalgia isn't what it used to be.

Re: `b'

[Simon Josefsson]

Kai Grossjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

>   > Is there a way from the article buffer to jump to (and display) part
>   > 42 then?  Couldn't `b' do this?
> 
> You can use TAB to move from button to button.

TAB does too many things for me, I just want to move to the next MIME
part. TAB jumps me to the next URL, stuff matching
gnus-signature-separator, MIME-part etc.

I'd really like some equivalents of TM/SEMI `n', `p' and `u' to
navigate in MIME articles.

>   > > Use RET.
>   > 
>   > Gives me a backtrace:
> 
> RET must be used when point is on a button.

Could we then bind RET to something that searches backwards for the
MIME-part button and then does what RET does today?  Finding a tiny
button to press RET on in a huge article is difficult (given the way
TAB works).

Or perhaps a key to jump to the top of the MIME-part, so I can do `key
RET' to hide a inline attachment I'm looking at?

/s

Re: `b'

[Kai Grossjohann]

>>>>> Simon Josefsson <jas@pdc.kth.se> writes:

  > TAB does too many things for me, I just want to move to the next
  > MIME part. TAB jumps me to the next URL, stuff matching
  > gnus-signature-separator, MIME-part etc.

Yes, maybe a function for moving between MIME parts, skipping the
other buttons, would be nice.

  > I'd really like some equivalents of TM/SEMI `n', `p' and `u' to
  > navigate in MIME articles.

Right.  Only we can't use these keys, they're already taken by Gnus.
And Lars wants the keys in the article to do the same thing as the
keys in the summary (except for RET, it seems :-).

  > Or perhaps a key to jump to the top of the MIME-part, so I can do `key
  > RET' to hide a inline attachment I'm looking at?

With the above, you don't need this, right?

kai
-- 
I wonder why nobody don't like me,
or is it de fact dat I'm ugly? -- Harry Belafonte

Re: `b'

[Simon Josefsson]

Kai Grossjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

>   > I'd really like some equivalents of TM/SEMI `n', `p' and `u' to
>   > navigate in MIME articles.
> 
> Right.  Only we can't use these keys, they're already taken by Gnus.
> And Lars wants the keys in the article to do the same thing as the
> keys in the summary (except for RET, it seems :-).

Ok. Will we have to use C-d to do operations on article parts then?  I
think C-d is nice, but I'd rather have one MIME viewer than two. And
if I've to pick, I'd like everything in one buffer like in the Article
buffer. I've often found myself wanting to reply to a message/rfc822
part, and I'd imagine the need to do other article operations on MIME
parts to increase once a MIME editor is avilable. :-)

>   > Or perhaps a key to jump to the top of the MIME-part, so I can do `key
>   > RET' to hide a inline attachment I'm looking at?
> 
> With the above, you don't need this, right?

Right.

/s

Re: `b'

[Lars Magne Ingebrigtsen]

Simon Josefsson <jas@pdc.kth.se> writes:

> Ok. Will we have to use C-d to do operations on article parts then?  I
> think C-d is nice, but I'd rather have one MIME viewer than two.

Well, I hope we get more than two MIME viewers.  I don't really like
either that we have now.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: `b'

[Lars Magne Ingebrigtsen]

Kai Grossjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

>   > I'd really like some equivalents of TM/SEMI `n', `p' and `u' to
>   > navigate in MIME articles.
> 
> Right.  Only we can't use these keys, they're already taken by Gnus.

Yup.  I kinda like that TAB goes to all the buttons.  But I guess
there could be a special go-to-MIME command, since that is probably
something that one wants more often...

In 0.35, `2 b' does go to MIME button 2, which may help some.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: `b'

[Lars Magne Ingebrigtsen]

Simon Josefsson <jas@pdc.kth.se> writes:

> Pressing `2 b' in a article with several text/plain parts hides the
> second part for me. It also doesn't change the cursor point, so when
> I'm reading the first part, pressing `2 b' only toggles wether the
> second part should be visible or not, it doesn't actually display the
> second part.

Yup.  Fix in Pterodactyl Gnus v0.35.

> Wouldn't it also be nice if I press `b' (no prefix), with the cursor
> in the article buffer on a MIME-part, and it toggles wether it should
> be displayed? Right now it toggles wether the first part should be
> displayed, regardless of where the cursor is in the article.

Yes -- `b' works the same in the summary and article buffers.  `RET'
does the thing you want in the article buffer.  I guess `b' could do
the same as `RET', but I'm not sure that's really logical.

> Btw, displaying a message/rfc822 part leaves me in a new buffer with
> the article, point at eob and in fundamental mode.

This works for me in 0.35.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen