bugGNU TeXmacs - Bugs: bug #18304, Nested folded-env lead to undue...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #18304: Nested folded-env lead to undue indentation

Submitted by:  Lionel Elie Mamane <lmamane>
Submitted on:  Wed 15 Nov 2006 12:00:44 PM UTC  
 
Category: TypesetterPriority: 5 - Normal
Item Group: ErrorStatus: Wont Fix
Privacy: PublicAssigned to: Joris van der Hoeven <vdhoeven>
Originator Name: Open/Closed: Closed
Release: CVS checkoutRelease: None
Fixed Release: NoneFixed Release: 
Keywords: 

(Jump to the original submission Jump to the original submission)

Thu 28 Nov 2013 01:16:58 PM UTC, comment #7:

I think that the current behaviour is not a bug, but a feature.

1) The bullets do not appear in print, because this environment is meant for producing interactively foldable environments, but normal looking Pdf output (e.g., it is extensively used in the book by Basu Pollack and Roy).

2) As Felix correctly points out, for nested folds in the first argument of the fold, we do not want the bullets to overlap. Actually, I think that this kind of nesting should be discouraged: usually, the first argument of the fold corresponds to some kind of title, whereas the second argument corresponds to a long body.

Joris van der Hoeven <vdhoeven>
Project AdministratorIn charge of this item.
Wed 13 Dec 2006 09:56:00 AM UTC, comment #6:

Indenting on screen, but not on print might have been the least bad solution, had it been possible.

I don't know a miracle solution to that problem, else I would have suggested it in the original report. That being said, one can imagine:

- There is actually place for two circle symbols in the margin, the rest is taken up by blank space in the box that turns green when you point your mouse on it. Just having the circle symbols take their "natural" space would allow nesting at level two instead of no nesting at all like now. Mock-up created with gimp attached.

- The two two-state circles may "merge" into one four-state widget (a thing that cycles between four states instead of two when double-clicked on). It could look like two partially overlapping circles. I can imagine this would be quite difficult to program, and would probably be more confusing than anything else for the user.

- The aforementioned unified widget could also give a contextual menu with the four choices when clicked.

- A fold-like construct that would have three arguments instead of two and behave like two nested folds (cycling between the four states).

The application is that I want to present the user four pieces of information a, b, c and d, where:

- a is grouped with b and c with d.
- Hiding the {c, d} group is one operation.
- Hiding b is one operation.
- Hiding d is one operation.
- The show/hide widgets are present on screen, but not in print.
- No effect on indentation a,b,c or d.
- Hidden parts don't take any vertical space.
- At least these states must be reachable:
* Only a shown
* Only a,b shown
* Only a,c shown
* Only a,b,c shown
* All of a,b,c,d shown

In particular, it would be acceptable if d could not be shown unless b and/or c is/are also shown. The best I could find up to now (except for this bug) is:

(unfolded-env
(unfolded-env a b)
(unfolded-env c d))

The next best thing:

(unfolded-env
(document
a
(detailed "" b))
(unfolded-env c d))

but then b always takes a line of vertical space.

Yes, I'm talking about the same version of TeXmacs all through this bug report.

(file #11513)

Lionel Elie Mamane <lmamane>
Fri 08 Dec 2006 02:01:53 PM UTC, comment #5:

BTW, what is the application for placing another fold inside the head of the outer fold?

Felix Breuer <fbreuer>
Project Member
Fri 08 Dec 2006 01:49:45 PM UTC, comment #4:

Markup inside a <specific> does not affect the positioning of markup outside the <specific> as shown by the attached specific.tm.

This makes it impossible to indent on screen but not on print. So, how do we avoid overlapping bullets on screen?

(file #11482)

Felix Breuer <fbreuer>
Project Member
Fri 08 Dec 2006 01:40:53 PM UTC, comment #3:

I see what you mean.

How should the bullets of nested folded-env's appear on screen? If they were not indented at all, they would overlap. Does indenting the text on screen but not on print sound good to you?

I had a brief look at the stylesheet. The problem is caused by the fact that only the bullet and not its surrounding <resize> is wrapped in the <specific>. Commuting the two does not help because a <resize> inside <specific|screen> has no effect on the screen layout: In the following snippet the B overlaps with the text "specific" when rendered on screen.

<resize|A|||r]1.5fn|>non-specific
<specific|screen|<resize|B|||r]1.5fn|>>specific-screen
<specific|print|<resize|C|||r]1.5fn|>>specific-print

I do not believe this is the desired effect...?

Felix Breuer <fbreuer>
Project Member
Fri 08 Dec 2006 12:03:56 PM UTC, comment #2:

Felix Breuer wrote:

> The result on screen and on print is supposed to be exactly the same.

That is factually not the case. The construct:

(unfolded-env "a" "b")

does not appear the same on screen and on print (and it does indeed use specific/screen constructs to achieve that effect if I remember well): the bullet/circle for interaction on screen does not appear on print. According to what you say, the interaction bullet/circle of unfolded-env should appear on print?

> The first argument of a (un)folded-env is thus indented

That's factually wrong. In that document:

(document
"a"
(unfolded-env "b" "c"))

The "a", "b" and "c" are all at the same indentation level. So the first argument of an unfolded-env is not indented normally, but is when they get nested; that's inconsistent, which is the subject of this bug report.

Lionel Elie Mamane <lmamane>
Thu 07 Dec 2006 10:18:23 PM UTC, comment #1:

The result on screen and on print is supposed to be exactly the same. The only way to hide something automatically in print is to use Insert->Specific->Screen. Folds can be used to emulate this by giving you the option to manually folding a portion of the document before printing: In <folded-env|a|b> the b is invisible.

However both the folded-env and the unfolded-env are preceeded by a bullet. The first argument of a (un)folded-env is thus indented. If you wish to avoid the bullet and hence the indentation use folded-plain and unfolded-plain.

To summarize: In 1.0.6.6 the "a" is preceeded by a bullet and thus indented in

<unfolded-env|
<unfolded-env|a|d>
<unfolded-env|b|c>|

>


but not in

<unfolded-env||
<unfolded-env|a|d>
<unfolded-env|b|c>

>


which is correct.

Felix Breuer <fbreuer>
Project Member
Wed 15 Nov 2006 12:00:44 PM UTC, original submission:

The following document snippet:

(unfolded-env
(unfolded-env "a" "d")
(unfolded-env "b" "c"))

leads to the "a" being more indented than the other lines, even on print. The purpose of unfolded-env is not to make any difference on print, right?

Lionel Elie Mamane <lmamane>

 

Attached Files
file #11513:  2006-12-13-092517_737x107_scrot.png added by lmamane (4KiB - image/png - Mockup for "there is place for two circles")
file #11482:  specific.tm added by fbreuer (360B - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by vdhoeven (Posted a comment)
  • -unavailable- added by lmamane (Updated the item)
  • -unavailable- added by fbreuer (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 12 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 28 Nov 2013 01:16:58 PM UTCvdhoevenStatusConfirmed=>Wont Fix
      Assigned toNone=>vdhoeven
      Open/ClosedOpen=>Closed
    Wed 13 Dec 2006 09:56:00 AM UTClmamaneAttached File-=>Added 2006-12-13-092517_737x107_scrot.png, #11513
    Wed 13 Dec 2006 08:17:19 AM UTClmamaneCarbon-CopyRemoved 13472=>-
    Fri 08 Dec 2006 01:49:45 PM UTCfbreuerAttached File-=>Added specific.tm, #11482
    Fri 08 Dec 2006 01:40:53 PM UTCfbreuerStatusWorks For Me=>Confirmed
      Open/ClosedClosed=>Open
    Fri 08 Dec 2006 11:54:17 AM UTClmamaneCarbon-Copy-=>Added lmamane
    Thu 07 Dec 2006 10:18:23 PM UTCfbreuerStatusNone=>Works For Me
      Open/ClosedOpen=>Closed
    Wed 15 Nov 2006 12:00:44 PM UTClmamaneCarbon-Copy-=>Added roconnor

    Back to the top


    Powered by Savane 3.1-cleanup1