Quantcast

Re: The Inbox: Collections-eem.732.mcz -- HtmlReadWriter

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Inbox: Collections-eem.732.mcz -- HtmlReadWriter

Hannes Hirzel
On 2/8/17, Tobias Pape <[hidden email]> wrote:

>
> On 08.02.2017, at 19:59, Eliot Miranda <[hidden email]> wrote:
>
>> Hi All,
>>
>>     I'd really like this to be in trunk.  I've just written a blog post in
>> a Workspace using this code
>> (http://www.mirandabanda.org/cogblog/2017/02/07/smalltalk-scanning-and-shcontrol-structures/)
>> and it turns creating a blog post into a simple copyHtml paste operation
>> from a workspace to (in my case) WordPress.  So any reviewers?
>
> Care to explain it a litte bit? :)
> It looks a bit complicated to my eyes.
> Also, do you really want <pre>?
> (http://stackoverflow.com/questions/4611591/code-vs-pre-vs-samp-for-inline-and-block-code-snippets#4611735)
>
> The HtmlReadWriter seems to (up until now) pretty directly map text
> attributes to html attributes.
>
> You seem to want to differentiate code from non-code, so what about having a
> do-it attribute, that does exactly that?
> Because now, there's also no back-reading of such html into a Text object,
> wich I find unfortunate.
> I think, the readwriter should be able to read what it has written.
>
> I know, it's a mere convenience thing, but still, its very procedural, and
> seeing #~~ in high-level code is strange to my eyes…
>
> What would be really cool is to
> - mark the code as do-it
> - have the do-it present itself as <code> or <pre> on Html.
+1

>
> Btw: there's also an TextIndent attribute that we could leverage.
>
> Best regards
> -Tobias
>
>
>>
>> On Wed, Feb 8, 2017 at 10:55 AM, <[hidden email]> wrote:
>> Eliot Miranda uploaded a new version of Collections to project The Inbox:
>> http://source.squeak.org/inbox/Collections-eem.732.mcz
>>
>> ==================== Summary ====================
>>
>> Name: Collections-eem.732
>> Author: eem
>> Time: 8 February 2017, 10:55:41.894202 am
>> UUID: c2c7f1c4-f586-4872-b2c7-6fb7f9cd6527
>> Ancestors: Collections-dtl.731
>>
>> Modify HtmlReadWriter to enclose indented text within <pre></pre> to
>> preserve formatting of, for example, code.
>>
>> =============== Diff against Collections-dtl.731 ===============
>>
>> Item was added:
>> + ----- Method: HtmlReadWriter>>linesWithAttributesIn:do: (in category
>> 'writing') -----
>> + linesWithAttributesIn: aText do: aBlock
>> +       "Evauate aBlock with a string and the emphasis for that string,
>> guaranteeing
>> +        that if the string contains a line break, it occurs at the end of
>> the line."
>> +       aText runs withStartStopAndValueDo:
>> +               [:start :stop :attributes | | att idx startIdx |
>> +                startIdx := start.
>> +                [att := aText attributesAt: startIdx.
>> +                 idx := aText string indexOf: Character cr from: startIdx
>> to: stop ifAbsent: stop.
>> +                 aBlock value: (aText string copyFrom: startIdx to: idx)
>> value: att.
>> +                 idx < stop]
>> +                       whileTrue:
>> +                               [startIdx := idx + 1]]!
>>
>> Item was changed:
>>   ----- Method: HtmlReadWriter>>nextPutText: (in category 'accessing')
>> -----
>>   nextPutText: aText
>> +       | atStartOfLine inIndent cr |
>> +       atStartOfLine := true.
>> +       inIndent := false.
>> +       cr := Character cr.
>> +       self linesWithAttributesIn: aText do:
>> +               [:string :attributes | | indented |
>> +               atStartOfLine ifTrue:
>> +                       [indented := string first == Character tab.
>> +                        indented ~~ inIndent ifTrue:
>> +                               [stream nextPutAll: (indented ifTrue:
>> ['<pre>'] ifFalse: ['</pre>']).
>> +                                inIndent := indented]].
>> +               attributes do: [:each | self writeStartTagFor: each].
>> +               inIndent
>> +                       ifTrue: [self writePresentationContent: string]
>> +                       ifFalse: [self writeContent: string].
>> +               attributes reverseDo: [:each | self writeEndTagFor: each].
>> +               atStartOfLine := string last == cr].
>> +       inIndent ifTrue:
>> +               [stream nextPutAll: '</pre>']!
>> -
>> -       aText runs
>> -               withStartStopAndValueDo: [:start :stop :attributes |
>> -                       | att str |
>> -                       att := aText attributesAt: start.
>> -                       str := aText string copyFrom: start to: stop.
>> -
>> -                       att do: [:each | self writeStartTagFor: each].
>> -                       self writeContent: str.
>> -                       att reverse do: [:each | self writeEndTagFor:
>> each]]!
>>
>> Item was added:
>> + ----- Method: HtmlReadWriter>>writePresentationContent: (in category
>> 'writing') -----
>> + writePresentationContent: aString
>> +
>> +       aString do: [:char |
>> +               char = Character tab
>> +                       ifTrue: [stream nextPutAll:
>> '&nbsp;&nbsp;&nbsp;&nbsp;']
>> +                       ifFalse: [(String htmlEntities keyAtValue: char
>> ifAbsent: [])
>> +                               ifNil: [stream nextPut: char]
>> +                               ifNotNil: [:escapeSequence |
>> +                                       stream
>> +                                               nextPut: $&;
>> +                                               nextPutAll:
>> escapeSequence;
>> +                                               nextPut: $;]]]!
>>
>> Item was added:
>> + ----- Method: SequenceableCollection>>indexOf:from:to:ifAbsent: (in
>> category 'accessing') -----
>> + indexOf: anElement from: start to: end ifAbsent: exceptionBlock
>> +       "Answer the index of the first occurence of anElement from start
>> to stop
>> +        within the receiver. If the receiver does not contain anElement
>> in the,
>> +        range answer the       result of evaluating the argument,
>> exceptionBlock."
>> +
>> +       start to: end do:
>> +               [:index |
>> +               (self at: index) = anElement ifTrue: [^index]].
>> +       ^exceptionBlock value!
>>
>>
>>
>>
>>
>> --
>> _,,,^..^,,,_
>> best, Eliot
>>
>
>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Inbox: Collections-eem.732.mcz -- HtmlReadWriter

Tobias Pape
Hi all,

On 09.02.2017, at 09:47, H. Hirzel <[hidden email]> wrote:

> On 2/8/17, Tobias Pape <[hidden email]> wrote:
>>
>> On 08.02.2017, at 19:59, Eliot Miranda <[hidden email]> wrote:
>>
>>> Hi All,
>>>
>>>    I'd really like this to be in trunk.  I've just written a blog post in
>>> a Workspace using this code
>>> (http://www.mirandabanda.org/cogblog/2017/02/07/smalltalk-scanning-and-shcontrol-structures/)
>>> and it turns creating a blog post into a simple copyHtml paste operation
>>> from a workspace to (in my case) WordPress.  So any reviewers?
>>
>> Care to explain it a litte bit? :)
>> It looks a bit complicated to my eyes.
>> Also, do you really want <pre>?
>> (http://stackoverflow.com/questions/4611591/code-vs-pre-vs-samp-for-inline-and-block-code-snippets#4611735)
>>
>> The HtmlReadWriter seems to (up until now) pretty directly map text
>> attributes to html attributes.
>>
>> You seem to want to differentiate code from non-code, so what about having a
>> do-it attribute, that does exactly that?
>> Because now, there's also no back-reading of such html into a Text object,
>> wich I find unfortunate.
>> I think, the readwriter should be able to read what it has written.
>>
>> I know, it's a mere convenience thing, but still, its very procedural, and
>> seeing #~~ in high-level code is strange to my eyes…
>>
>> What would be really cool is to
>> - mark the code as do-it
>> - have the do-it present itself as <code> or <pre> on Html.
> +1

So with Bert's help, I did just that (see trunk).

Workflow for Eliot could be now:
 - Write text in workspace
 - Copy (formatted) code to workspace
 - [Attention: new] select the code and CMD-6 it as DoIt
   (code is now clickable and underlined)
 - repeat until satisfied
 - yellow-click and 'copy as html'

Also, there are two test for this behavior now.

HTH

Best regards
        -Tobias



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Inbox: Collections-eem.732.mcz -- HtmlReadWriter

Eliot Miranda-2
Hi Tobias,

On Thu, Feb 9, 2017 at 10:54 AM, Tobias Pape <[hidden email]> wrote:
Hi all,

On 09.02.2017, at 09:47, H. Hirzel <[hidden email]> wrote:

> On 2/8/17, Tobias Pape <[hidden email]> wrote:
>>
>> On 08.02.2017, at 19:59, Eliot Miranda <[hidden email]> wrote:
>>
>>> Hi All,
>>>
>>>    I'd really like this to be in trunk.  I've just written a blog post in
>>> a Workspace using this code
>>> (http://www.mirandabanda.org/cogblog/2017/02/07/smalltalk-scanning-and-shcontrol-structures/)
>>> and it turns creating a blog post into a simple copyHtml paste operation
>>> from a workspace to (in my case) WordPress.  So any reviewers?
>>
>> Care to explain it a litte bit? :)
>> It looks a bit complicated to my eyes.
>> Also, do you really want <pre>?
>> (http://stackoverflow.com/questions/4611591/code-vs-pre-vs-samp-for-inline-and-block-code-snippets#4611735)
>>
>> The HtmlReadWriter seems to (up until now) pretty directly map text
>> attributes to html attributes.
>>
>> You seem to want to differentiate code from non-code, so what about having a
>> do-it attribute, that does exactly that?
>> Because now, there's also no back-reading of such html into a Text object,
>> wich I find unfortunate.
>> I think, the readwriter should be able to read what it has written.
>>
>> I know, it's a mere convenience thing, but still, its very procedural, and
>> seeing #~~ in high-level code is strange to my eyes…
>>
>> What would be really cool is to
>>      - mark the code as do-it
>>      - have the do-it present itself as <code> or <pre> on Html.
> +1

So with Bert's help, I did just that (see trunk).

Workflow for Eliot could be now:
 - Write text in workspace
 - Copy (formatted) code to workspace
 - [Attention: new] select the code and CMD-6 it as DoIt
   (code is now clickable and underlined)
 - repeat until satisfied
 - yellow-click and 'copy as html'

Thanks for your efforts, but, forgive me for saying so, this is worse than my approach.  <pre> is designed to preserve wits-space, and indented text needs this.  If there's a bug with my code it is that it looks for tab at start-of-like rather than whitespace.  Can we merge our code?  IMO your approach should cause text marked as a Doit to be generated between <code></code> markers, where as there is still a need for generating non-Doit code between <pre></pre> markers.  If you don't object I'll merge in my code.
 

Also, there are two test for this behavior now.

HTH

Best regards
        -Tobias






--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Inbox: Collections-eem.732.mcz -- HtmlReadWriter

Eliot Miranda-2
Tobias,

  ignore my email.  I'm reviewing your code.  But I will say that adding inst vars is making things more complicated too.  I added three methods to achieve what I wanted and you've added 8 and an inst var ;-)

On Thu, Feb 9, 2017 at 11:13 AM, Eliot Miranda <[hidden email]> wrote:
Hi Tobias,

On Thu, Feb 9, 2017 at 10:54 AM, Tobias Pape <[hidden email]> wrote:
Hi all,

On 09.02.2017, at 09:47, H. Hirzel <[hidden email]> wrote:

> On 2/8/17, Tobias Pape <[hidden email]> wrote:
>>
>> On 08.02.2017, at 19:59, Eliot Miranda <[hidden email]> wrote:
>>
>>> Hi All,
>>>
>>>    I'd really like this to be in trunk.  I've just written a blog post in
>>> a Workspace using this code
>>> (http://www.mirandabanda.org/cogblog/2017/02/07/smalltalk-scanning-and-shcontrol-structures/)
>>> and it turns creating a blog post into a simple copyHtml paste operation
>>> from a workspace to (in my case) WordPress.  So any reviewers?
>>
>> Care to explain it a litte bit? :)
>> It looks a bit complicated to my eyes.
>> Also, do you really want <pre>?
>> (http://stackoverflow.com/questions/4611591/code-vs-pre-vs-samp-for-inline-and-block-code-snippets#4611735)
>>
>> The HtmlReadWriter seems to (up until now) pretty directly map text
>> attributes to html attributes.
>>
>> You seem to want to differentiate code from non-code, so what about having a
>> do-it attribute, that does exactly that?
>> Because now, there's also no back-reading of such html into a Text object,
>> wich I find unfortunate.
>> I think, the readwriter should be able to read what it has written.
>>
>> I know, it's a mere convenience thing, but still, its very procedural, and
>> seeing #~~ in high-level code is strange to my eyes…
>>
>> What would be really cool is to
>>      - mark the code as do-it
>>      - have the do-it present itself as <code> or <pre> on Html.
> +1

So with Bert's help, I did just that (see trunk).

Workflow for Eliot could be now:
 - Write text in workspace
 - Copy (formatted) code to workspace
 - [Attention: new] select the code and CMD-6 it as DoIt
   (code is now clickable and underlined)
 - repeat until satisfied
 - yellow-click and 'copy as html'

Thanks for your efforts, but, forgive me for saying so, this is worse than my approach.  <pre> is designed to preserve wits-space, and indented text needs this.  If there's a bug with my code it is that it looks for tab at start-of-like rather than whitespace.  Can we merge our code?  IMO your approach should cause text marked as a Doit to be generated between <code></code> markers, where as there is still a need for generating non-Doit code between <pre></pre> markers.  If you don't object I'll merge in my code.
 

Also, there are two test for this behavior now.

HTH

Best regards
        -Tobias






--
_,,,^..^,,,_
best, Eliot



--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Inbox: Collections-eem.732.mcz -- HtmlReadWriter

Eliot Miranda-2
In reply to this post by Tobias Pape
Hi Tobias,

On Thu, Feb 9, 2017 at 10:54 AM, Tobias Pape <[hidden email]> wrote:
Hi all,

On 09.02.2017, at 09:47, H. Hirzel <[hidden email]> wrote:

> On 2/8/17, Tobias Pape <[hidden email]> wrote:
>>
>> On 08.02.2017, at 19:59, Eliot Miranda <[hidden email]> wrote:
>>
>>> Hi All,
>>>
>>>    I'd really like this to be in trunk.  I've just written a blog post in
>>> a Workspace using this code
>>> (http://www.mirandabanda.org/cogblog/2017/02/07/smalltalk-scanning-and-shcontrol-structures/)
>>> and it turns creating a blog post into a simple copyHtml paste operation
>>> from a workspace to (in my case) WordPress.  So any reviewers?
>>
>> Care to explain it a litte bit? :)
>> It looks a bit complicated to my eyes.
>> Also, do you really want <pre>?
>> (http://stackoverflow.com/questions/4611591/code-vs-pre-vs-samp-for-inline-and-block-code-snippets#4611735)
>>
>> The HtmlReadWriter seems to (up until now) pretty directly map text
>> attributes to html attributes.
>>
>> You seem to want to differentiate code from non-code, so what about having a
>> do-it attribute, that does exactly that?
>> Because now, there's also no back-reading of such html into a Text object,
>> wich I find unfortunate.
>> I think, the readwriter should be able to read what it has written.
>>
>> I know, it's a mere convenience thing, but still, its very procedural, and
>> seeing #~~ in high-level code is strange to my eyes…
>>
>> What would be really cool is to
>>      - mark the code as do-it
>>      - have the do-it present itself as <code> or <pre> on Html.
> +1

So with Bert's help, I did just that (see trunk).

Workflow for Eliot could be now:
 - Write text in workspace
 - Copy (formatted) code to workspace
 - [Attention: new] select the code and CMD-6 it as DoIt
   (code is now clickable and underlined)
 - repeat until satisfied
 - yellow-click and 'copy as html'

Also, there are two test for this behavior now.

What I want in addition is the ability to enclose indented text in <pre></pre>.  i.e. I am free /not/ to use TextDoit/<code></code> if I don't want them (I find the side bar as ugly as hell; and there are plenty of use cases for indented text that have nothing to do with code).  Are you motivated to provide this?


HTH

Best regards
        -Tobias






--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Inbox: Collections-eem.732.mcz -- HtmlReadWriter

Bert Freudenberg
In reply to this post by Eliot Miranda-2
On Thu, Feb 9, 2017 at 8:16 PM, Eliot Miranda <[hidden email]> wrote:
Tobias,

  ignore my email.  I'm reviewing your code.  But I will say that adding inst vars is making things more complicated too.  I added three methods to achieve what I wanted and you've added 8 and an inst var ;-)

The problem with your indentation-based approach was that when just copying a whole method as HTML, it would insert a <pre> tag *after* the method pattern (because that was the first indented line). That's why Tobi added the TextDoit stuff, to specifically mark code ... It's still not ideal but we couldn't come up with a better way for unifying your blog-post-in-a-workspace with the regular just-copy-some-code. Ideas welcome :)

- Bert -


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Inbox: Collections-eem.732.mcz -- HtmlReadWriter

Eliot Miranda-2


On Thu, Feb 9, 2017 at 11:44 AM, Bert Freudenberg <[hidden email]> wrote:
On Thu, Feb 9, 2017 at 8:16 PM, Eliot Miranda <[hidden email]> wrote:
Tobias,

  ignore my email.  I'm reviewing your code.  But I will say that adding inst vars is making things more complicated too.  I added three methods to achieve what I wanted and you've added 8 and an inst var ;-)

The problem with your indentation-based approach was that when just copying a whole method as HTML, it would insert a <pre> tag *after* the method pattern (because that was the first indented line).

Thats not quite true.  My code adds the <pre> before indenting because of the variable initializations.  But it does indeed insert the closing </pre> after the last carriage return and that's a bug.

 
That's why Tobi added the TextDoit stuff, to specifically mark code ... It's still not ideal but we couldn't come up with a better way for unifying your blog-post-in-a-workspace with the regular just-copy-some-code. Ideas welcome :)

When examining the end of line, the code could easily peek ahead and look at the next line.  This would allow it to add the </pre> before the last carriage return.  So to sketch the algorithm, the high-level iterator over texts breaks text into lines, arranging that line breaks occur only as the last character of the text, and the iterator provides the next character after the line break, or nil of none.  The code can then easily arrange to add the closing </pre> before the carriage return since it is informed of the character following the line break:

linesWithAttributesIn: aText do: aTrinaryBlock
    "Evauate aTrinaryBlock with a string and the emphasis for that string, guaranteeing
     that if the string contains a line break, it occurs at the end of the line, and the
     chanarcter following the line break if it exists."
    aText runs withStartStopAndValueDo:
        [:start :stop :attributes | | att idx startIdx |
         startIdx := start.
         [att := aText attributesAt: startIdx.
          idx := aText string indexOf: Character cr from: startIdx to: stop ifAbsent: stop.
          aTrinaryBlock
            value: (aText string copyFrom: startIdx to: idx)
            value: att
            value: (idx < stop ifTrue: [aText string at: idx + 1]).
          idx < stop]
            whileTrue:
                [startIdx := idx + 1]]


BTW, it would be *really cool* if "copy html" also copied the generated text to the system (OS) paste buffer as formatted HTML so I wouldn't have to paste the generated HTML into a Workspace, say "export to file...", open the HTML file in a web browser, and copy that text :-(  (or am I missing a trick??)


- Bert -






--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Inbox: Collections-eem.732.mcz -- HtmlReadWriter

Eliot Miranda-2
In reply to this post by Bert Freudenberg


On Thu, Feb 9, 2017 at 11:44 AM, Bert Freudenberg <[hidden email]> wrote:
On Thu, Feb 9, 2017 at 8:16 PM, Eliot Miranda <[hidden email]> wrote:
Tobias,

  ignore my email.  I'm reviewing your code.  But I will say that adding inst vars is making things more complicated too.  I added three methods to achieve what I wanted and you've added 8 and an inst var ;-)

The problem with your indentation-based approach was that when just copying a whole method as HTML, it would insert a <pre> tag *after* the method pattern (because that was the first indented line). That's why Tobi added the TextDoit stuff, to specifically mark code ... It's still not ideal but we couldn't come up with a better way for unifying your blog-post-in-a-workspace with the regular just-copy-some-code. Ideas welcome :)

OK, accepted, but if one is considering simply a text with indentation, say

This is a non-indented line.
    This is an indented line.
This is another unindented line.

We need to generate

 This is a non-indented line.<br>
<pre>    This is an indented line.
</pre>
This is another unindented line.<br>

Right?  Right now there is no way to achieve this.  Adding a <code></code> tag pair around the indented line is wrong.  Having to mark it as a doit is wrong.  But the only way to preserve the indentation is to use <pre>.  That's what my changes (save arguably adding the closing </pre> in the wrong place) achieved.  No need to mark things as dots.  One simply indents, and whitespace is preserved.  Simple.


- Bert -






--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Inbox: Collections-eem.732.mcz -- HtmlReadWriter

Tobias Pape

On 09.02.2017, at 21:06, Eliot Miranda <[hidden email]> wrote:

>
> OK, accepted, but if one is considering simply a text with indentation, say
>
> This is a non-indented line.
>     This is an indented line.
> This is another unindented line.
>
> We need to generate
>
>  This is a non-indented line.<br>
> <pre>    This is an indented line.
> </pre>
> This is another unindented line.<br>
>
> Right?  Right now there is no way to achieve this.  Adding a <code></code> tag pair around the indented line is wrong.  Having to mark it as a doit is wrong.  But the only way to preserve the indentation is to use <pre>.  That's what my changes (save arguably adding the closing </pre> in the wrong place) achieved.  No need to mark things as dots.  One simply indents, and whitespace is preserved.  Simple.

No, that circumvents text attributes.

I understand you want the second line indented the way you proposed, but that's not the complete truth for any text.
Because Pararaph indents, because non-code intents, because reflow (<pre> does _not_ reflow).

So the following would come out as <pre>, but that's completely unacceptable:

Voluptatem est adipisci explicabo sequi numquam sunt et quo. Possimus sunt illum culpa. Excepturi dolorum asperiores tenetur. Asperiores culpa quia dolorem eum esse et. Qui suscipit consequatur modi et. Nisi quod id hic odio.
        Reprehenderit ratione aut enim. Sed mollitia vero sed fugit iure. Quibusdam nostrum expedita dolor rerum repellat suscipit aliquam. Alias quo et nostrum est.
Qui minima hic ullam. Et iure sint sint et. Ut velit debitis qui sunt corrupti id odit asperiores.


Actually, there's a TextIndent attribute, we should make use of it (add working key code, add working html generation).

Best regards
        -Tobias



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Inbox: Collections-eem.732.mcz -- HtmlReadWriter

Tobias Pape
In reply to this post by Eliot Miranda-2

On 09.02.2017, at 20:16, Eliot Miranda <[hidden email]> wrote:

> Tobias,
>
>   ignore my email.  I'm reviewing your code.  But I will say that adding inst vars is making things more complicated too.  I added three methods to achieve what I wanted and you've added 8 and an inst var ;-)
>

Yes, clearly. Because it is the duty of the attribute to care for its formatting, not some hard-coded value in the generating method. ;)
I actually am about to write a MarkDown readwriter, so this generality is justified :D ;)


> On Thu, Feb 9, 2017 at 11:13 AM, Eliot Miranda <[hidden email]> wrote:
> Hi Tobias,
>
> On Thu, Feb 9, 2017 at 10:54 AM, Tobias Pape <[hidden email]> wrote:
> Hi all,
>
> On 09.02.2017, at 09:47, H. Hirzel <[hidden email]> wrote:
>
> > On 2/8/17, Tobias Pape <[hidden email]> wrote:
> >>
> >> On 08.02.2017, at 19:59, Eliot Miranda <[hidden email]> wrote:
> >>
> >>> Hi All,
> >>>
> >>>    I'd really like this to be in trunk.  I've just written a blog post in
> >>> a Workspace using this code
> >>> (http://www.mirandabanda.org/cogblog/2017/02/07/smalltalk-scanning-and-shcontrol-structures/)
> >>> and it turns creating a blog post into a simple copyHtml paste operation
> >>> from a workspace to (in my case) WordPress.  So any reviewers?
> >>
> >> Care to explain it a litte bit? :)
> >> It looks a bit complicated to my eyes.
> >> Also, do you really want <pre>?
> >> (http://stackoverflow.com/questions/4611591/code-vs-pre-vs-samp-for-inline-and-block-code-snippets#4611735)
> >>
> >> The HtmlReadWriter seems to (up until now) pretty directly map text
> >> attributes to html attributes.
> >>
> >> You seem to want to differentiate code from non-code, so what about having a
> >> do-it attribute, that does exactly that?
> >> Because now, there's also no back-reading of such html into a Text object,
> >> wich I find unfortunate.
> >> I think, the readwriter should be able to read what it has written.
> >>
> >> I know, it's a mere convenience thing, but still, its very procedural, and
> >> seeing #~~ in high-level code is strange to my eyes…
> >>
> >> What would be really cool is to
> >>      - mark the code as do-it
> >>      - have the do-it present itself as <code> or <pre> on Html.
> > +1
>
> So with Bert's help, I did just that (see trunk).
>
> Workflow for Eliot could be now:
>  - Write text in workspace
>  - Copy (formatted) code to workspace
>  - [Attention: new] select the code and CMD-6 it as DoIt
>    (code is now clickable and underlined)
>  - repeat until satisfied
>  - yellow-click and 'copy as html'
>
> Thanks for your efforts, but, forgive me for saying so, this is worse than my approach.  <pre> is designed to preserve wits-space, and indented text needs this.  If there's a bug with my code it is that it looks for tab at start-of-like rather than whitespace.  Can we merge our code?  IMO your approach should cause text marked as a Doit to be generated between <code></code> markers, where as there is still a need for generating non-Doit code between <pre></pre> markers.  If you don't object I'll merge in my code.
>  
>
> Also, there are two test for this behavior now.
>
> HTH
>
> Best regards
>         -Tobias
>
>
>
>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Inbox: Collections-eem.732.mcz -- HtmlReadWriter

Eliot Miranda-2
In reply to this post by Tobias Pape


On Thu, Feb 9, 2017 at 12:11 PM, Tobias Pape <[hidden email]> wrote:

On 09.02.2017, at 21:06, Eliot Miranda <[hidden email]> wrote:

>
> OK, accepted, but if one is considering simply a text with indentation, say
>
> This is a non-indented line.
>     This is an indented line.
> This is another unindented line.
>
> We need to generate
>
>  This is a non-indented line.<br>
> <pre>    This is an indented line.
> </pre>
> This is another unindented line.<br>
>
> Right?  Right now there is no way to achieve this.  Adding a <code></code> tag pair around the indented line is wrong.  Having to mark it as a doit is wrong.  But the only way to preserve the indentation is to use <pre>.  That's what my changes (save arguably adding the closing </pre> in the wrong place) achieved.  No need to mark things as dots.  One simply indents, and whitespace is preserved.  Simple.

No, that circumvents text attributes.

I understand you want the second line indented the way you proposed, but that's not the complete truth for any text.
Because Pararaph indents, because non-code intents, because reflow (<pre> does _not_ reflow).

So the following would come out as <pre>, but that's completely unacceptable:

Voluptatem est adipisci explicabo sequi numquam sunt et quo. Possimus sunt illum culpa. Excepturi dolorum asperiores tenetur. Asperiores culpa quia dolorem eum esse et. Qui suscipit consequatur modi et. Nisi quod id hic odio.
        Reprehenderit ratione aut enim. Sed mollitia vero sed fugit iure. Quibusdam nostrum expedita dolor rerum repellat suscipit aliquam. Alias quo et nostrum est.
Qui minima hic ullam. Et iure sint sint et. Ut velit debitis qui sunt corrupti id odit asperiores.

But the current scheme loses the pargraph indent anyway.   So my way is no worse.  The current scheme throws away all indentation.  The current UI doesn't provide a way of setting paragraph indent.  So we're in a situation where if one wants to indent we can only do so by applying a <code></code> tag pair (and applying an invisible emphasis to a text).  I think this is poor.  My simple approach doesn't lose indenting, does mean that one can't use an initial paragraph indent, but does allow one, easily, and visibly, to generate correctly indented HTML.  I know what I want to chose right now.  You're forcing me to wait a long time for the right solution.  I want to generate well-formatted blog posts now.




Actually, there's a TextIndent attribute, we should make use of it (add working key code, add working html generation).

Best regards
        -Tobias






--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Inbox: Collections-eem.732.mcz -- HtmlReadWriter

Eliot Miranda-2


On Thu, Feb 9, 2017 at 3:56 PM, Eliot Miranda <[hidden email]> wrote:


On Thu, Feb 9, 2017 at 12:11 PM, Tobias Pape <[hidden email]> wrote:

On 09.02.2017, at 21:06, Eliot Miranda <[hidden email]> wrote:

>
> OK, accepted, but if one is considering simply a text with indentation, say
>
> This is a non-indented line.
>     This is an indented line.
> This is another unindented line.
>
> We need to generate
>
>  This is a non-indented line.<br>
> <pre>    This is an indented line.
> </pre>
> This is another unindented line.<br>
>
> Right?  Right now there is no way to achieve this.  Adding a <code></code> tag pair around the indented line is wrong.  Having to mark it as a doit is wrong.  But the only way to preserve the indentation is to use <pre>.  That's what my changes (save arguably adding the closing </pre> in the wrong place) achieved.  No need to mark things as dots.  One simply indents, and whitespace is preserved.  Simple.

No, that circumvents text attributes.

I understand you want the second line indented the way you proposed, but that's not the complete truth for any text.
Because Pararaph indents, because non-code intents, because reflow (<pre> does _not_ reflow).

So the following would come out as <pre>, but that's completely unacceptable:

Voluptatem est adipisci explicabo sequi numquam sunt et quo. Possimus sunt illum culpa. Excepturi dolorum asperiores tenetur. Asperiores culpa quia dolorem eum esse et. Qui suscipit consequatur modi et. Nisi quod id hic odio.
        Reprehenderit ratione aut enim. Sed mollitia vero sed fugit iure. Quibusdam nostrum expedita dolor rerum repellat suscipit aliquam. Alias quo et nostrum est.
Qui minima hic ullam. Et iure sint sint et. Ut velit debitis qui sunt corrupti id odit asperiores.

But the current scheme loses the pargraph indent anyway.   So my way is no worse.  The current scheme throws away all indentation.  The current UI doesn't provide a way of setting paragraph indent.  So we're in a situation where if one wants to indent we can only do so by applying a <code></code> tag pair (and applying an invisible emphasis to a text).  I think this is poor.  My simple approach doesn't lose indenting, does mean that one can't use an initial paragraph indent, but does allow one, easily, and visibly, to generate correctly indented HTML.  I know what I want to chose right now.  You're forcing me to wait a long time for the right solution.  I want to generate well-formatted blog posts now.

and what is HtmlReadWriter  and TextWriter doing in Collections anyway?  If it were in a text generation package I'd have a chance of maintaining my fork while I wait for a functional system that easily supports generating blog posts.  Right now I have little chance of affording to maintain a fork given that this is in Collections of all places :-(





Actually, there's a TextIndent attribute, we should make use of it (add working key code, add working html generation).

Best regards
        -Tobias






--
_,,,^..^,,,_
best, Eliot



--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Inbox: Collections-eem.732.mcz -- HtmlReadWriter

Paul DeBruicker
In reply to this post by Tobias Pape
Tobias Pape wrote
Because Pararaph indents, because non-code intents, because reflow (<pre> does _not_ reflow).

pre can reflow with these CSS rules:

  pre {
        white-space: pre-wrap;       /* css-3 */
        white-space: -moz-pre-wrap;  /* Mozilla, since 1999 */
        white-space: -pre-wrap;      /* Opera 4-6 */
        white-space: -o-pre-wrap;    /* Opera 7 */
        word-wrap: break-word;       /* Internet Explorer 5.5+ */
    }


see https://developer.mozilla.org/en-US/docs/Web/CSS/white-space for other options.


Hope this helps


Paul
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Inbox: Collections-eem.732.mcz -- HtmlReadWriter

Tobias Pape
In reply to this post by Eliot Miranda-2

On 10.02.2017, at 00:56, Eliot Miranda <[hidden email]> wrote:

> But the current scheme loses the pargraph indent anyway.  

No, it doesn't?

writeContent: aString

        aString do: [:char |
                (#(10 13) includes: char asciiValue)
                        ifTrue: [self cr]
                        ifFalse: [char = Character tab
                                ifTrue: [self nextPutAll: '&nbsp;&nbsp;&nbsp;&nbsp;']
                                ifFalse: [(String htmlEntities keyAtValue: char ifAbsent: [])
                                        ifNil: [self nextPut: char]
                                        ifNotNil: [:escapeSequence |
                                                self
                                                        nextPut: $&;
                                                        nextPutAll: escapeSequence;
                                                        nextPut: $;]]]].

Tabs are expanded to four non-breaking spaces.
How's that losing the indent.

> So my way is no worse.  The current scheme throws away all indentation.

No, see above.

>  The current UI doesn't provide a way of setting paragraph indent.  So we're in a situation where if one wants to indent we can only do so by applying a <code></code> tag pair (and applying an invisible emphasis to a text).  I think this is poor.  My simple approach doesn't lose indenting, does mean that one can't use an initial paragraph indent, but does allow one, easily, and visibly, to generate correctly indented HTML.
>  I know what I want to chose right now.  You're forcing me to wait a long time for the right solution.  I want to generate well-formatted blog posts now.

So, lets look: Object>>orderedCollection

Old code/new code, yellow-click, copy as html:
=======================================
<b>asOrderedCollection</b><font color="#000000"><br>
&nbsp;&nbsp;&nbsp;&nbsp;</font><font color="#007F7F">&quot;Answer an OrderedCollection with the receiver as its only element.&quot;</font><font color="#000000"><br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;</font><font color="#7F0000">^</font><font color="#000000"> </font><font color="#000000">OrderedCollection</font><font color="#000000"> </font><font color="#00007F">with:</font><font color="#000000"> </font><font color="#7F0000">self</font>
=======================================
Observations:
- colors preserved
- indents preserved!
- Reflows when window too small.
- line breaks correctly honored
- w/o styling, all serif.


New code, select all, cmd-6/doit, yellow-click, copy as html:
=======================================
<code>
<pre><b>asOrderedCollection</b><font color="#000000">
&nbsp;&nbsp;&nbsp;&nbsp;</font><font color="#007F7F">&quot;Answer an OrderedCollection with the receiver as its only element.&quot;</font><font color="#000000">

&nbsp;&nbsp;&nbsp;&nbsp;</font><font color="#7F0000">^</font><font color="#000000"> OrderedCollection </font><font color="#00007F">with:</font><font color="#000000"> </font><font color="#7F0000">self</font></pre></code>
=======================================
Observations:
- colors preserved
- indents preserved!
- keeps lines, no reflow when window too small.
- line breaks correctly honored
- w/o styling, all monospaced.


inbox version, yellow-click, copy as html:
=======================================
<b>asOrderedCollection</b><font color="#000000"><br>
</font><pre><font color="#000000">&nbsp;&nbsp;&nbsp;&nbsp;</font><font color="#007F7F">&quot;Answer an OrderedCollection with the receiver as its only element.&quot;</font><font color="#000000">
</font></pre><font color="#000000"><br>
</font><pre><font color="#000000">&nbsp;&nbsp;&nbsp;&nbsp;</font><font color="#7F0000">^</font><font color="#000000"> </font><font color="#000000">OrderedCollection</font><font color="#000000"> </font><font color="#00007F">with:</font><font color="#000000"> </font><font color="#7F0000">self</font></pre>
=======================================
Observations:
- colors preserved
- indents preserved and explicitly colored?
- keeps lines, no reflow when window too small.
- line breaks incorrect, there's an additional space between comment and return?
- first line styled different from rest of method?


So what it does: wrap every _line_ with indent into a <pre>. I find that confusing.
Also, mark-with-doit version is opt-in, inbox-verison is not.

See also attached html and attached screenshot.
I have included a comparison for the indented paragraph example, also.

Best regards
        -Tobias



Object_asOrderedCollection.html (2K) Download Attachment
Bildschirmfoto 2017-02-10 um 08.58.23.PNG (344K) Download Attachment
Bildschirmfoto 2017-02-10 um 09.02.54.PNG (367K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: The Inbox: Collections-eem.732.mcz -- HtmlReadWriter

Hannes Hirzel
Nice!

On 2/10/17, Tobias Pape <[hidden email]> wrote:

>
> On 10.02.2017, at 00:56, Eliot Miranda <[hidden email]> wrote:
>
>> But the current scheme loses the pargraph indent anyway.
>
> No, it doesn't?
>
> writeContent: aString
>
> aString do: [:char |
> (#(10 13) includes: char asciiValue)
> ifTrue: [self cr]
> ifFalse: [char = Character tab
> ifTrue: [self nextPutAll: '&nbsp;&nbsp;&nbsp;&nbsp;']
> ifFalse: [(String htmlEntities keyAtValue: char ifAbsent: [])
> ifNil: [self nextPut: char]
> ifNotNil: [:escapeSequence |
> self
> nextPut: $&;
> nextPutAll: escapeSequence;
> nextPut: $;]]]].
>
> Tabs are expanded to four non-breaking spaces.
> How's that losing the indent.
>
>> So my way is no worse.  The current scheme throws away all indentation.
>
> No, see above.
>
>>  The current UI doesn't provide a way of setting paragraph indent.  So
>> we're in a situation where if one wants to indent we can only do so by
>> applying a <code></code> tag pair (and applying an invisible emphasis to a
>> text).  I think this is poor.  My simple approach doesn't lose indenting,
>> does mean that one can't use an initial paragraph indent, but does allow
>> one, easily, and visibly, to generate correctly indented HTML.
>>  I know what I want to chose right now.  You're forcing me to wait a long
>> time for the right solution.  I want to generate well-formatted blog posts
>> now.
>
> So, lets look: Object>>orderedCollection
>
> Old code/new code, yellow-click, copy as html:
> =======================================
> <b>asOrderedCollection</b><font color="#000000"><br>
> &nbsp;&nbsp;&nbsp;&nbsp;</font><font color="#007F7F">&quot;Answer an
> OrderedCollection with the receiver as its only element.&quot;</font><font
> color="#000000"><br>
> <br>
> &nbsp;&nbsp;&nbsp;&nbsp;</font><font color="#7F0000">^</font><font
> color="#000000"> </font><font color="#000000">OrderedCollection</font><font
> color="#000000"> </font><font color="#00007F">with:</font><font
> color="#000000"> </font><font color="#7F0000">self</font>
> =======================================
> Observations:
> - colors preserved
> - indents preserved!
> - Reflows when window too small.
> - line breaks correctly honored
> - w/o styling, all serif.
>
>
> New code, select all, cmd-6/doit, yellow-click, copy as html:
> =======================================
> <code>
> <pre><b>asOrderedCollection</b><font color="#000000">
> &nbsp;&nbsp;&nbsp;&nbsp;</font><font color="#007F7F">&quot;Answer an
> OrderedCollection with the receiver as its only element.&quot;</font><font
> color="#000000">
>
> &nbsp;&nbsp;&nbsp;&nbsp;</font><font color="#7F0000">^</font><font
> color="#000000"> OrderedCollection </font><font
> color="#00007F">with:</font><font color="#000000"> </font><font
> color="#7F0000">self</font></pre></code>
> =======================================
> Observations:
> - colors preserved
> - indents preserved!
> - keeps lines, no reflow when window too small.
> - line breaks correctly honored
> - w/o styling, all monospaced.
>
>
> inbox version, yellow-click, copy as html:
> =======================================
> <b>asOrderedCollection</b><font color="#000000"><br>
> </font><pre><font color="#000000">&nbsp;&nbsp;&nbsp;&nbsp;</font><font
> color="#007F7F">&quot;Answer an OrderedCollection with the receiver as its
> only element.&quot;</font><font color="#000000">
> </font></pre><font color="#000000"><br>
> </font><pre><font color="#000000">&nbsp;&nbsp;&nbsp;&nbsp;</font><font
> color="#7F0000">^</font><font color="#000000"> </font><font
> color="#000000">OrderedCollection</font><font color="#000000"> </font><font
> color="#00007F">with:</font><font color="#000000"> </font><font
> color="#7F0000">self</font></pre>
> =======================================
> Observations:
> - colors preserved
> - indents preserved and explicitly colored?
> - keeps lines, no reflow when window too small.
> - line breaks incorrect, there's an additional space between comment and
> return?
> - first line styled different from rest of method?
>
>
> So what it does: wrap every _line_ with indent into a <pre>. I find that
> confusing.
> Also, mark-with-doit version is opt-in, inbox-verison is not.
>
> See also attached html and attached screenshot.
> I have included a comparison for the indented paragraph example, also.
>
> Best regards
> -Tobias
>

Loading...