Preferences ignoreStyleIfOnlyBold

I want to turn this into a pragma-based preference. I don't know on
which class to hang the preference though. On Text?

I'd be happy with adding Text >> #ignoreStyleIfOnlyBold because (a)
Text is the only sender and (b) Text is all about styling.

(The ulterior motive is that adding Text >> #ignoreStyleIfOnlyBold
breaks another strand in the Collections -> System dependency.)

frank

Do we even want to keep this preference?  What is it for?  The
description tells us _what_ it does, not why it does it...

On Sun, Dec 29, 2013 at 1:56 PM, Frank Shearar <[hidden email]> wrote:

A preference to make "cut and pasting" of code easier?  And this on
top of the fact that we have a hot-key to remove all formatting
(Cmd+0).

On top of that, Shout makes it irrelevant doesn't it?  It does not
appear Shout can even be disabled anymore --
#syntaxHighlightingAsYouType has no effect and no senders.


On Mon, Dec 30, 2013 at 4:28 PM, karl ramberg <[hidden email]> wrote:

On 30 December 2013 22:43, Chris Muller <[hidden email]> wrote:
> A preference to make "cut and pasting" of code easier?  And this on
> top of the fact that we have a hot-key to remove all formatting
> (Cmd+0).
>
> On top of that, Shout makes it irrelevant doesn't it?  It does not
> appear Shout can even be disabled anymore --
> #syntaxHighlightingAsYouType has no effect and no senders.

You could give this preference teeth once more, I think, by adjusting
PluggableTextMorphPlus >> #okToStyle:

okToStyle
    styler ifNil:[^false].
    (model respondsTo: #aboutToStyle: ) ifFalse:[^true].
    SHTextStylerST80 syntaxHighlightingAsYouType ifFalse: [^ true].
    ^model aboutToStyle: styler

(You could of course use 'Smalltalk classNamed: #SHTextStylerST80' and
so on, which would prevent a "static" dependency on ShoutCore.)

This would let morphs respond instantly to a preference change. Or you
could change MorphicToolBuilder >> #buildPluggableCodePane: so that it
only sent #useDefaultStyler when the preference was set to true.

If you cared that strongly about NOT styling your code.

frank

Cut-and-pasting _should_ be painful, so you will be encouraged to
write factored code instead.  :)

You want to c&p that "self initialize" don't you?  Ha ha, just kidding!!  :-)

Besides, I don't think one hot-key Cmd+0 is all that painful anyway.

But wait!  If you're using Shout, how will you stop the method from
being styled as soon as you type the next character?

And, if you're not using Shout then "cut" will be cutting plain text anyway..

So, unless I'm missing something, this preference seems so useless its crazy.

On 31 December 2013 16:48, Chris Muller <[hidden email]> wrote:
Specifically, _copy_ and pasting should be painful. Cut-n-paste is
nearly Extract Method!

It does seem that way to me. It looks like pre-Shout cruft.

frank

On 31 December 2013 16:51, Frank Shearar <[hidden email]> wrote:
Ignore this. Too many Preference discussions floating around. _This_
preference doesn't look like pre-Shout cruft. It's the
#askIfAddStyle:req: stuff that smells like stale cruft sauce to me.

frank

On 31-12-2013, at 11:54 AM, Colin Putney <[hidden email]> wrote:
> Yeah, this preference isn't quite right for my purposes. The behaviour I want is that Shout does syntax highlighting for me, but the text is otherwise treated as unstyled. If I cut it, the clipboard has unstyled text, if I paste styled text, the styles are ignored and Shout restyles it according to syntax. Unstyled text gets stored in the changes file and Monticello.
>
> The problem I have now is that if I cut Shout-styled text and paste it into a browser, I get a dialog asking me if I want styled text. The answer is always no, so I'd rather not be asked about it every time.

Yeah, pretty much how I’d put it. Code shouldn’t be styled text in general - if Shout wants to do some style for *rendering purposes* that’s tolerable but this isn’t a word processor. I’d say that copy from a code view should copy plain text and if you paste it into a styled wordprocessor view it should be plain. Pasting into a code view, even from a styled wordprocessor view  should paste in plain text (that may get prettied by Shout).

There’s one case where style is appropriate for code, and that is in a system where the code is intermingled with the spec/design/description/commentary. Such a style would be to mark it for the attention of the compiler/tools.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Fac ut gaudeam = Make my day.

On 31.12.2013, at 21:15, tim Rowledge <[hidden email]> wrote:

>
> On 31-12-2013, at 11:54 AM, Colin Putney <[hidden email]> wrote:
>> Yeah, this preference isn't quite right for my purposes. The behaviour I want is that Shout does syntax highlighting for me, but the text is otherwise treated as unstyled. If I cut it, the clipboard has unstyled text, if I paste styled text, the styles are ignored and Shout restyles it according to syntax. Unstyled text gets stored in the changes file and Monticello.
>>
>> The problem I have now is that if I cut Shout-styled text and paste it into a browser, I get a dialog asking me if I want styled text. The answer is always no, so I'd rather not be asked about it every time.
>
> Yeah, pretty much how I’d put it. Code shouldn’t be styled text in general - if Shout wants to do some style for *rendering purposes* that’s tolerable but this isn’t a word processor.

Just askin, why not?

> I’d say that copy from a code view should copy plain text and if you paste it into a styled wordprocessor view it should be plain. Pasting into a code view, even from a styled wordprocessor view  should paste in plain text (that may get prettied by Shout).
>
> There’s one case where style is appropriate for code, and that is in a system where the code is intermingled with the spec/design/description/commentary. Such a style would be to mark it for the attention of the compiler/tools.

Best
        -Tobias

On 31-12-2013, at 12:53 PM, Tobias Pape <[hidden email]> wrote:

That’s actually a good question to discuss. I think at root it’s a personal preference, most likely derived largely from having been at this stuff for 30 years and being ancient and grumpy. However, there are defensible aspects to my view as well; at least, I think they are and maybe you have good counter-arguments we can consider.

Code tools that we have to maintain ought to be kept as simple as possible whilst doing the job well. Simpler code is simpler to fix & improve. Well, duh ;-) I also think that a lot of style stuff distracts from the readability of code, making the job harder than it needs to be. One of my objections to Shout is the time it takes to do all the pretty bits - and of course the analysis that generates the prettiness - but I find the colouring distracting almost all the time. I sort of appreciate the distinction for comments and misspelled class/variable names but the method names checking, local variable colouring etc drive me nuts. Aside from anything else it completely misses the point that single level affordances usually don’t convey adequate information - if you’re colour blind, for example, variant colours are unlikely to be helpful. Thoughtful use of bold/italic type changes would possibly improve things.

Handling sophisticated styling is a distraction from making the tool as good and fast as bug-free as possible in my view. I know of course that ParagraphEditor et al are used for code views and that they have done basic style for even longer than I’ve been using them. Now that we have lovely outline fonts in the world, with all the style possibilities they present, perhaps it would be good to simplify out a CodeEditor that just does plain (but still proportional!) text and lots of good code-editing things, like regexp and.. whatever, whilst leaving out styles. Then make a better ParagraphEditor that does nice text layout and leaves out the code editing stuff. A word processor needs good undo/redo handling, spell checking, style maintenance & creation tools - none of which is simple. Just ask the team that worked on the Sophie Project. Oh, wait, that included me, too.

I can see, by the way, that with people liking Shout functionality it may be essential to leave the basic style handing in the code tools; I wouldn’t fume and rail against that idea too loudly. So perhaps the practical solution these days is to make sure the style capability to support that is kept in CodeEditor and subclass that to start a swish ParagraphEditor.

Speed is important too. Most of us spend most of our time running mind-bogglingly fast machines that can blast their way past complex Shout processing whilst simultaneously ripping a dozen bluray movies, but important work is done on slow machines too. The basic tools need to work well on a Pi or even slower machines (OLPC is probably the slowest widely used, at a guess) and the flashy stuff ought to degrade gracefully whenever possible.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: SDJ: Send all Data to Japan

On 31.12.2013, at 23:21, tim Rowledge <[hidden email]> wrote:
None yet but the obvious legibility straw-man:
Code is more often read than written and formatting (aka Typography)
helps a lot. (-> “TeX the Program” is interestingly good to read).

If you can decide yourself what to call attention on, you can help the
dear reader to convey your intentions.

Also, it is always a question, what “style” or “rich text” means.
For example, just a few days ago, I remembered that it is possible
to make hyperlinks in Squeak Text. So I wanted to do:

myMehtod: foo
  " see #mySimilarMethod for rationale "
  stuff...

and wanted to make #mySimilarMethod a link (which is possible in normal
Workspace, for example). But it was immediately lost upon saving...

Another thing: CodeTalk
  https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/codetalk
We use Text styling to provide chats on/in the code
as kind-of enhanced comments. Paper is here: http://www.taeumel.eu/writings.html


>
> Code tools that we have to maintain ought to be kept as simple as possible whilst doing the job well. Simpler code is simpler to fix & improve. Well, duh ;-) I also think that a lot of style stuff distracts from the readability of code, making the job harder than it needs to be. One of my objections to Shout is the time it takes to do all the pretty bits - and of course the analysis that generates the prettiness - but I find the colouring distracting almost all the time. I sort of appreciate the distinction for comments and misspelled class/variable names but the method names checking, local variable colouring etc drive me nuts. Aside from anything else it completely misses the point that single level affordances usually don’t convey adequate information - if you’re colour blind, for example, variant colours are unlikely to be helpful. Thoughtful use of bold/italic type changes would possibly improve things.

Well… apart from the color blindness issue (which is important but rather limiting here):
I have recognized that the shout coloring (especially the “subdued” variant, with limited
use of black and bold) gives me information about methods that I can “see” rather than “read”.
I notice this often, at least twice a year when grading students’ code.

• A method with a lot of read is probably missing cascades, or the interface is somehow too fine grained
• A method with much blue and more than a little bit of grey certainly is not written
  in OO style: no much self sends, a lot of temporaries.
• A method with red and black mixed probably isn’t consistent in the use of accessor/instance variable access.

and so on.
So, shout gives me the possibility to get a feeling for the code _before_ I actually read it.

>
> Handling sophisticated styling is a distraction from making the tool as good and fast as bug-free as possible in my view. I know of course that ParagraphEditor et al are used for code views and that they have done basic style for even longer than I’ve been using them. Now that we have lovely outline fonts in the world, with all the style possibilities they present, perhaps it would be good to simplify out a CodeEditor that just does plain (but still proportional!) text and lots of good code-editing things, like regexp and.. whatever, whilst leaving out styles. Then make a better ParagraphEditor that does nice text layout and leaves out the code editing stuff.

> A word processor needs good undo/redo handling,

So does code handling. Really. Ours is messed up.

> spell checking,

So should  (and does: https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/dicThesaurusRex )
code handling!

> style maintenance & creation tools - none of which is simple.

Maintenance, yes, creation, I don’t think so (my humble opinion)

> Just ask the team that worked on the Sophie Project. Oh, wait, that included me, too.

:) I know people from the Sophie Server Team.

>
> I can see, by the way, that with people liking Shout functionality it may be essential to leave the basic style handing in the code tools; I wouldn’t fume and rail against that idea too loudly. So perhaps the practical solution these days is to make sure the style capability to support that is kept in CodeEditor and subclass that to start a swish ParagraphEditor.
>
> Speed is important too. Most of us spend most of our time running mind-bogglingly fast machines that can blast their way past complex Shout processing whilst simultaneously ripping a dozen bluray movies, but important work is done on slow machines too. The basic tools need to work well on a Pi or even slower machines (OLPC is probably the slowest widely used, at a guess) and the flashy stuff ought to degrade gracefully whenever possible.

OK. I can align to the last one.
But I think we have more severe speed hogs than shout
(eg, morphic drawing everything, even the invisible stuff, 3 times and more...)

Probably, thinking of code more as “stuff-to-be-read” and playing out the
consequences is, while not new, not a thing thought out to its ends.

Best
        -Tobias

On 31 December 2013 19:54, Colin Putney <[hidden email]> wrote:
For what it's worth, things still seem to work just fine if you rip
out #askIfAddStyle:req: and adjust ClassDescription >>
logMethodSource:forMethodWithNode:inCategory:withStamp:notifying:
accordingly. That might not mean particularly much. At any rate,
logging here means storing in the changes file. What the implications
styling (or the lack thereof) _of methods_ has for the changes file I
do not know. Since Shout styles code, I don't see what the problem
would be with simply removing all styling of all source on its way to
the changes file (so in the ClassDescription method above).
(Obviously, class comments are different, and we should preserve
styling here. But that's a different code path.)

In other words, why can't we replace

newText := (requestor notNil and: [Preferences confirmFirstUseOfStyle])
    ifTrue: [aText askIfAddStyle: priorMethodOrNil req: requestor]
    ifFalse: [aText].

with aText asString?

frank

> Colin

On Fri, Jan 3, 2014 at 3:35 AM, Frank Shearar <[hidden email]> wrote:
+1.  I agree with your reasoning -- there's no obviously good reason
to store styled Text in the changes file.

If you make this change, please "garbage collect"
confirmFirstUseOfStyle from Preferences too, so it's not dangling out
there unreferenced and useless.

On 3 January 2014 16:33, Chris Muller <[hidden email]> wrote:
OK, so that's you & I in agreement. I think Colin's happy for it to
go. Any ol' timers out there with warnings of doom, before I rip this
out?

> If you make this change, please "garbage collect"
> confirmFirstUseOfStyle from Preferences too, so it's not dangling out
> there unreferenced and useless.

Yep!

frank

On Fri, Jan 03, 2014 at 05:03:56PM +0000, Frank Shearar wrote:
Does this effect hyperlinks in class comments and methos source?

Dave

On 3 January 2014 17:33, David T. Lewis <[hidden email]> wrote:
As far as I can make out it would leave class comments unharmed,
because Compiler sends #logMethodSource:too:long:to:type: only when
saving methods.

My suggestion as it stands right now would nuke hyperlinks in method
source. If we don't want to do that, we could just use "aText" then,
and always save styled code.

frank

On 03.01.2014, at 18:03, Frank Shearar <[hidden email]> wrote:
Just FYI: this makes it impossible to use/port CodeTalk[1] in/to
Squeak 4.5.
And I actually used it once or twice, not that this would be important :)

Best
        -Tobias

[1] https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/codetalk