[squeak-dev] Preferences ignoreStyleIfOnlyBold

Tobias Pape Das.Linux at gmx.de
Wed Jan 1 12:29:26 UTC 2014


On 31.12.2013, at 23:21, tim Rowledge <tim at rowledge.org> wrote:

> 
> On 31-12-2013, at 12:53 PM, Tobias Pape <Das.Linux at gmx.de> wrote:
> 
>> 
>> On 31.12.2013, at 21:15, tim Rowledge <tim at rowledge.org> wrote:
>> 
>>> 
>>> On 31-12-2013, at 11:54 AM, Colin Putney <colin at 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/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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1665 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140101/4cde0e74/signature.pgp


More information about the Squeak-dev mailing list