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 frank.shearar@gmail.com wrote:
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
When saving a method with bold font you will not get asked if you want to save/ preserve the font style.
When copy pasting you can get a method selectors in bold somewhere in the code. Most likely you will not want to keep that formatting.
Karl
On Mon, Dec 30, 2013 at 10:13 PM, Chris Muller asqueaker@gmail.com wrote:
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 frank.shearar@gmail.com wrote:
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
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 karlramberg@gmail.com wrote:
When saving a method with bold font you will not get asked if you want to save/ preserve the font style.
When copy pasting you can get a method selectors in bold somewhere in the code. Most likely you will not want to keep that formatting.
Karl
On Mon, Dec 30, 2013 at 10:13 PM, Chris Muller asqueaker@gmail.com wrote:
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 frank.shearar@gmail.com wrote:
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
On Mon, Dec 30, 2013 at 5:43 PM, Chris Muller asqueaker@gmail.com 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).
Yeah. You got a problem with cut-and-paste?
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.
Actually, I'd like to see the preference change to #ignoreStyleWhenPastingCode or something like that. With Shout, code is always styled, and it makes pasting it a pain.
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).
Yeah. You got a problem with cut-and-paste?
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.
Actually, I'd like to see the preference change to #ignoreStyleWhenPastingCode or something like that. With Shout, code is always styled, and it makes pasting it a pain.
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 asqueaker@gmail.com 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).
Yeah. You got a problem with cut-and-paste?
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.
Actually, I'd like to see the preference change to #ignoreStyleWhenPastingCode or something like that. With Shout, code is always styled, and it makes pasting it a pain.
Cut-and-pasting _should_ be painful, so you will be encouraged to write factored code instead. :)
Specifically, _copy_ and pasting should be painful. Cut-n-paste is nearly Extract Method!
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.
It does seem that way to me. It looks like pre-Shout cruft.
frank
On 31 December 2013 16:51, Frank Shearar frank.shearar@gmail.com wrote:
On 31 December 2013 16:48, Chris Muller asqueaker@gmail.com 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).
Yeah. You got a problem with cut-and-paste?
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.
Actually, I'd like to see the preference change to #ignoreStyleWhenPastingCode or something like that. With Shout, code is always styled, and it makes pasting it a pain.
Cut-and-pasting _should_ be painful, so you will be encouraged to write factored code instead. :)
Specifically, _copy_ and pasting should be painful. Cut-n-paste is nearly Extract Method!
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.
It does seem that way to me. It looks like pre-Shout cruft.
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 Tue, Dec 31, 2013 at 11:48 AM, Chris Muller asqueaker@gmail.com wrote:
Cut-and-pasting _should_ be painful, so you will be encouraged to write factored code instead. :)
I do write factored code. I just don't like typing it all out by hand.
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.
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.
Colin
On 31-12-2013, at 11:54 AM, Colin Putney colin@wiresong.com 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; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Fac ut gaudeam = Make my day.
On 31.12.2013, at 21:15, tim Rowledge tim@rowledge.org wrote:
On 31-12-2013, at 11:54 AM, Colin Putney colin@wiresong.com 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 Das.Linux@gmx.de wrote:
On 31.12.2013, at 21:15, tim Rowledge tim@rowledge.org wrote:
On 31-12-2013, at 11:54 AM, Colin Putney colin@wiresong.com 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?
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; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: SDJ: Send all Data to Japan
On 31.12.2013, at 23:21, tim Rowledge tim@rowledge.org wrote:
On 31-12-2013, at 12:53 PM, Tobias Pape Das.Linux@gmx.de wrote:
On 31.12.2013, at 21:15, tim Rowledge tim@rowledge.org wrote:
On 31-12-2013, at 11:54 AM, Colin Putney colin@wiresong.com 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?
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.
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/... 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/... ) 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 colin@wiresong.com wrote:
On Tue, Dec 31, 2013 at 11:48 AM, Chris Muller asqueaker@gmail.com wrote:
Cut-and-pasting _should_ be painful, so you will be encouraged to write factored code instead. :)
I do write factored code. I just don't like typing it all out by hand.
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.
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.
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 frank.shearar@gmail.com wrote:
On 31 December 2013 19:54, Colin Putney colin@wiresong.com wrote:
On Tue, Dec 31, 2013 at 11:48 AM, Chris Muller asqueaker@gmail.com wrote:
Cut-and-pasting _should_ be painful, so you will be encouraged to write factored code instead. :)
I do write factored code. I just don't like typing it all out by hand.
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.
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.
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?
+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 asqueaker@gmail.com wrote:
On Fri, Jan 3, 2014 at 3:35 AM, Frank Shearar frank.shearar@gmail.com wrote:
On 31 December 2013 19:54, Colin Putney colin@wiresong.com wrote:
On Tue, Dec 31, 2013 at 11:48 AM, Chris Muller asqueaker@gmail.com wrote:
Cut-and-pasting _should_ be painful, so you will be encouraged to write factored code instead. :)
I do write factored code. I just don't like typing it all out by hand.
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.
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.
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?
+1. I agree with your reasoning -- there's no obviously good reason to store styled Text in the changes file.
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:
On 3 January 2014 16:33, Chris Muller asqueaker@gmail.com wrote:
On Fri, Jan 3, 2014 at 3:35 AM, Frank Shearar frank.shearar@gmail.com wrote:
On 31 December 2013 19:54, Colin Putney colin@wiresong.com wrote:
On Tue, Dec 31, 2013 at 11:48 AM, Chris Muller asqueaker@gmail.com wrote:
Cut-and-pasting _should_ be painful, so you will be encouraged to write factored code instead. :)
I do write factored code. I just don't like typing it all out by hand.
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.
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.
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?
+1. I agree with your reasoning -- there's no obviously good reason to store styled Text in the changes file.
Does this effect hyperlinks in class comments and methos source?
Dave
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 3 January 2014 17:33, David T. Lewis lewis@mail.msen.com wrote:
On Fri, Jan 03, 2014 at 05:03:56PM +0000, Frank Shearar wrote:
On 3 January 2014 16:33, Chris Muller asqueaker@gmail.com wrote:
On Fri, Jan 3, 2014 at 3:35 AM, Frank Shearar frank.shearar@gmail.com wrote:
On 31 December 2013 19:54, Colin Putney colin@wiresong.com wrote:
On Tue, Dec 31, 2013 at 11:48 AM, Chris Muller asqueaker@gmail.com wrote:
Cut-and-pasting _should_ be painful, so you will be encouraged to write factored code instead. :)
I do write factored code. I just don't like typing it all out by hand.
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.
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.
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?
+1. I agree with your reasoning -- there's no obviously good reason to store styled Text in the changes file.
Does this effect hyperlinks in class comments and methos source?
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
Dave
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 03.01.2014, at 18:03, Frank Shearar frank.shearar@gmail.com wrote:
On 3 January 2014 16:33, Chris Muller asqueaker@gmail.com wrote:
On Fri, Jan 3, 2014 at 3:35 AM, Frank Shearar frank.shearar@gmail.com wrote:
On 31 December 2013 19:54, Colin Putney colin@wiresong.com wrote:
On Tue, Dec 31, 2013 at 11:48 AM, Chris Muller asqueaker@gmail.com wrote:
Cut-and-pasting _should_ be painful, so you will be encouraged to write factored code instead. :)
I do write factored code. I just don't like typing it all out by hand.
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.
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.
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?
+1. I agree with your reasoning -- there's no obviously good reason to store styled Text in the changes file.
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?
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/...
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?
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 :)
Oh, that does matter. Tobias, I think you're saying CodeTalk wants to store Text into the .changes and possibly MC because that's where it stores its code annotations. Is that right? But they don't actually need that preference too do they?
We should account for Robert Hirschfelds group which has put out some great tools and projects. CodeTalk wants to continue to push Smalltalk ahead of the rest of the world still stuck in plain-text.
So, based on this, I think we should not change policy w.r.t. storing Text vs. Strings. Text has #asString, so it doesn't seem there should be any extra complexity to deal with the outside world; probably less than trying to rip out something that's integrated and works.
[1] https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/...
On 03.01.2014, at 20:18, Chris Muller ma.chris.m@gmail.com 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?
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 :)
Oh, that does matter. Tobias, I think you're saying CodeTalk wants to store Text into the .changes and possibly MC because that's where it stores its code annotations. Is that right? But they don't actually need that preference too do they?
It just stores its information as text attributes, which then goes to the Changes file, IIRC. It has to patch monticello in order to save the information but that is independent of the style stuff.
As a matter of fact, CodeTalk forces the Preference to be ON.
We should account for Robert Hirschfelds group which has put out some great tools and projects. CodeTalk wants to continue to push Smalltalk ahead of the rest of the world still stuck in plain-text.
So, based on this, I think we should not change policy w.r.t. storing Text vs. Strings. Text has #asString, so it doesn't seem there should be any extra complexity to deal with the outside world; probably less than trying to rip out something that's integrated and works.
Thanks.
Best -Tobias
[1] https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/...
On 3 January 2014 19:32, Tobias Pape Das.Linux@gmx.de wrote:
On 03.01.2014, at 20:18, Chris Muller ma.chris.m@gmail.com 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?
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 :)
Oh, that does matter. Tobias, I think you're saying CodeTalk wants to store Text into the .changes and possibly MC because that's where it stores its code annotations. Is that right? But they don't actually need that preference too do they?
It just stores its information as text attributes, which then goes to the Changes file, IIRC. It has to patch monticello in order to save the information but that is independent of the style stuff.
As a matter of fact, CodeTalk forces the Preference to be ON.
So effectively CodeTalk turns
newText := (requestor notNil and: [Preferences confirmFirstUseOfStyle]) ifTrue: [aText askIfAddStyle: priorMethodOrNil req: requestor] ifFalse: [aText]
into aText?
Doing that means we can rip out #askIfAddStyle:req and Preferences confirmFirstUseOfStyle. That would sever the Collections -> Tools dependency, and would be a late Christmas treat for me.
frank
We should account for Robert Hirschfelds group which has put out some great tools and projects. CodeTalk wants to continue to push Smalltalk ahead of the rest of the world still stuck in plain-text.
So, based on this, I think we should not change policy w.r.t. storing Text vs. Strings. Text has #asString, so it doesn't seem there should be any extra complexity to deal with the outside world; probably less than trying to rip out something that's integrated and works.
Thanks.
Best -Tobias
[1] https://www.hpi.uni-potsdam.de/hirschfeld/trac/SqueakCommunityProjects/wiki/...
On Fri, Jan 3, 2014 at 1:36 PM, Frank Shearar frank.shearar@gmail.com wrote:
On 3 January 2014 19:32, Tobias Pape Das.Linux@gmx.de wrote:
On 03.01.2014, at 20:18, Chris Muller ma.chris.m@gmail.com 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?
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 :)
Oh, that does matter. Tobias, I think you're saying CodeTalk wants to store Text into the .changes and possibly MC because that's where it stores its code annotations. Is that right? But they don't actually need that preference too do they?
It just stores its information as text attributes, which then goes to the Changes file, IIRC. It has to patch monticello in order to save the information but that is independent of the style stuff.
As a matter of fact, CodeTalk forces the Preference to be ON.
So effectively CodeTalk turns
newText := (requestor notNil and: [Preferences confirmFirstUseOfStyle]) ifTrue: [aText askIfAddStyle: priorMethodOrNil req: requestor] ifFalse: [aText]
into aText?
Yes, it would seem newText var can be removed (along with the pref) and just use aText.
On 03.01.2014, at 20:36, Frank Shearar frank.shearar@gmail.com wrote:
On 3 January 2014 19:32, Tobias Pape Das.Linux@gmx.de wrote:
On 03.01.2014, at 20:18, Chris Muller ma.chris.m@gmail.com 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?
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 :)
Oh, that does matter. Tobias, I think you're saying CodeTalk wants to store Text into the .changes and possibly MC because that's where it stores its code annotations. Is that right? But they don't actually need that preference too do they?
It just stores its information as text attributes, which then goes to the Changes file, IIRC. It has to patch monticello in order to save the information but that is independent of the style stuff.
As a matter of fact, CodeTalk forces the Preference to be ON.
So effectively CodeTalk turns
newText := (requestor notNil and: [Preferences confirmFirstUseOfStyle]) ifTrue: [aText askIfAddStyle: priorMethodOrNil req: requestor] ifFalse: [aText]
into aText?
effectively.
Doing that means we can rip out #askIfAddStyle:req and Preferences confirmFirstUseOfStyle. That would sever the Collections -> Tools dependency, and would be a late Christmas treat for me.
*g*
but make sure there is an #asString before any of that enters the compiler.
Best -Tobias
On 3 January 2014 19:58, Tobias Pape Das.Linux@gmx.de wrote:
On 03.01.2014, at 20:36, Frank Shearar frank.shearar@gmail.com wrote:
On 3 January 2014 19:32, Tobias Pape Das.Linux@gmx.de wrote:
On 03.01.2014, at 20:18, Chris Muller ma.chris.m@gmail.com 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?
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 :)
Oh, that does matter. Tobias, I think you're saying CodeTalk wants to store Text into the .changes and possibly MC because that's where it stores its code annotations. Is that right? But they don't actually need that preference too do they?
It just stores its information as text attributes, which then goes to the Changes file, IIRC. It has to patch monticello in order to save the information but that is independent of the style stuff.
As a matter of fact, CodeTalk forces the Preference to be ON.
So effectively CodeTalk turns
newText := (requestor notNil and: [Preferences confirmFirstUseOfStyle]) ifTrue: [aText askIfAddStyle: priorMethodOrNil req: requestor] ifFalse: [aText]
into aText?
effectively.
Doing that means we can rip out #askIfAddStyle:req and Preferences confirmFirstUseOfStyle. That would sever the Collections -> Tools dependency, and would be a late Christmas treat for me.
*g*
but make sure there is an #asString before any of that enters the compiler.
Not a problem in this case, because logging takes place after compilation.
Best -Tobias
frank
On Fri, Jan 3, 2014 at 12:03 PM, Frank Shearar frank.shearar@gmail.comwrote:
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?
No, I certainly wouldn't miss it.
I will say this, however. I don't know if it goes all the way back to ST-80, but I do remember that styled code was considered important in the early days of Squeak. I seem to remember some tweaks to Monticello when it first came out that would allow it to store styled code the same way it's stored in the changes file. IIRC we even supported hyperlinks in code, although I don't remember actually seeing one in the wild.
Therefore, we ought to decide if this is a change in policy—i.e., we're going to support plain-text source code only—or if we're just rejiggering preferences for better modularity. If it's a policy change, we have a free hand simplify the codebase accordingly, take styling commands out of code editors and so on. It doesn't have to be done right away, but let's consider that on the agenda for 4.6.
On the other hand, if we consider styled source code important, we should figure out how to change the preferences to play nicely with Shout for those who use it, while still retaining the ability to manually style code and persist those styles along with the content of the code.
Personally, I'd vote for plain-text only code. I can see the value of styled code, but that's not the way the world went, and it's no longer worth the complexity or friction when dealing with the world outside of the image.
Colin
On 3 January 2014 17:57, Colin Putney colin@wiresong.com wrote:
On Fri, Jan 3, 2014 at 12:03 PM, Frank Shearar frank.shearar@gmail.com 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?
No, I certainly wouldn't miss it.
I will say this, however. I don't know if it goes all the way back to ST-80, but I do remember that styled code was considered important in the early days of Squeak. I seem to remember some tweaks to Monticello when it first came out that would allow it to store styled code the same way it's stored in the changes file. IIRC we even supported hyperlinks in code, although I don't remember actually seeing one in the wild.
Therefore, we ought to decide if this is a change in policy—i.e., we're going to support plain-text source code only—or if we're just rejiggering preferences for better modularity. If it's a policy change, we have a free hand simplify the codebase accordingly, take styling commands out of code editors and so on. It doesn't have to be done right away, but let's consider that on the agenda for 4.6.
On the other hand, if we consider styled source code important, we should figure out how to change the preferences to play nicely with Shout for those who use it, while still retaining the ability to manually style code and persist those styles along with the content of the code.
Personally, I'd vote for plain-text only code. I can see the value of styled code, but that's not the way the world went, and it's no longer worth the complexity or friction when dealing with the world outside of the image.
My vote is also for plain-text only code. But my vote is _also_ for not screwing things up for Chris while he works on getting 4.5 out the door.
David has an Inbox that will, when pushed to trunk, break the final strand between Collections and System. The snapping of that rubber band would satisfy me for 4.5's purposes.
This preference causes a Collections -> Tools dependency which, transitively, means it still depends on System. The Tools <-> System entanglement is too large for me to untangle in the 4.5 release timeframe, so I vote for voting on plan text vs styled text in 4.6.
(I am A-OK with styling in class comments though, even though I've not actually used any styling. (And class comments could do with an edit pane or something, so the UI can tell me how to use these fancy links in the first place.))
frank
Colin
My vote is also for plain-text only code. But my vote is _also_ for not screwing things up for Chris while he works on getting 4.5 out the door.
David has an Inbox that will, when pushed to trunk, break the final strand between Collections and System. The snapping of that rubber band would satisfy me for 4.5's purposes.
Ah, thank you! +1
This preference causes a Collections -> Tools dependency which, transitively, means it still depends on System. The Tools <-> System entanglement is too large for me to untangle in the 4.5 release timeframe, so I vote for voting on plan text vs styled text in 4.6.
(I am A-OK with styling in class comments though, even though I've not actually used any styling. (And class comments could do with an edit pane or something, so the UI can tell me how to use these fancy links in the first place.))
As luck would have it, I just finished writing a set of unit tests to verify filein and fileout capability of text attributes. This is included in CollectionsTests-dtl.209 in the inbox. I think this may make it somewhat easier to understand and maintain the support for styled text in code.
http://lists.squeakfoundation.org/pipermail/squeak-dev/2014-January/175795.h...
As a matter of policy, it seems to me that since source code can be (and sometimes is) in the form of styled text, and given that various people have found interesting uses for this over the years, we should not do something to make that impossible.
I also agree that it is preferable to store source code as plain text wherever possible. I just would not want to make it impossible to store styled text in the cases where someone has a good reason to do so.
Dave
On Fri, Jan 3, 2014 at 12:03 PM, Frank Shearar frank.shearar@gmail.comwrote:
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?
No, I certainly wouldn't miss it.
I will say this, however. I don't know if it goes all the way back to ST-80, but I do remember that styled code was considered important in the early days of Squeak. I seem to remember some tweaks to Monticello when it first came out that would allow it to store styled code the same way it's stored in the changes file. IIRC we even supported hyperlinks in code, although I don't remember actually seeing one in the wild.
Therefore, we ought to decide if this is a change in policyi.e., we're going to support plain-text source code onlyor if we're just rejiggering preferences for better modularity. If it's a policy change, we have a free hand simplify the codebase accordingly, take styling commands out of code editors and so on. It doesn't have to be done right away, but let's consider that on the agenda for 4.6.
On the other hand, if we consider styled source code important, we should figure out how to change the preferences to play nicely with Shout for those who use it, while still retaining the ability to manually style code and persist those styles along with the content of the code.
Personally, I'd vote for plain-text only code. I can see the value of styled code, but that's not the way the world went, and it's no longer worth the complexity or friction when dealing with the world outside of the image.
Colin
On 30 December 2013 22:43, Chris Muller asqueaker@gmail.com 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
On Mon, Dec 30, 2013 at 4:28 PM, karl ramberg karlramberg@gmail.com wrote:
When saving a method with bold font you will not get asked if you want to save/ preserve the font style.
When copy pasting you can get a method selectors in bold somewhere in the code. Most likely you will not want to keep that formatting.
Karl
On Mon, Dec 30, 2013 at 10:13 PM, Chris Muller asqueaker@gmail.com wrote:
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 frank.shearar@gmail.com wrote:
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
squeak-dev@lists.squeakfoundation.org
-
Chris Muller -
Chris Muller -
Colin Putney -
David T. Lewis -
Frank Shearar -
karl ramberg -
tim Rowledge -
Tobias Pape