[OS X TeX] New Macros, new Engines, new TeXShop versions, and all that

[Claus Gerhardt]

TeXShop is the only application that I know which offers a comparable macro facility where the user can attach his own key short-cuts to a macro. David's proposal which you seem to support would require that TS offers two separate macro facilities a default set where the user can only temporarily attach  key short-cuts (up to the next update) and a user defined set.

I guess this would be feasible but the failure to assign sticking key short-cuts plus the additional effort in writing the code raises the question if the trouble would be worth the gains. In my humble opinion definitely not, especially since the alternative (I only have the naive user in mind since the other users are apparently a negligible quantity) only requires that the user deletes a certain folder whenever the software has been updated, and even this task can be automated to avoid any demands which could be deemed as being excessive.

Claus

P.S.: I happen to dislike scrolling to the bottom of a message before I can read the new text though it would never occur to me to ask others to top-post their messages.

On Feb 22, 2010, at 0:58, Alan Munn wrote:

> On Feb 21, 2010, at 2:53 PM, Gerrit Glabbart wrote:
> 
>> 
>> 
>> 2010/2/21 David Messerschmitt <messer at eecs.berkeley.edu>
>> 
>> Good point, but there is absolutely nothing inconsistent between (a) accommodating naive and power users differently and (b) allowing users to move from the naive to the power category. All you are saying is that naive users should not matter, because they dont stay that way. Such a perspective is commonplace in open source software, but I am arguing that naive users are important. For one thing, accommodating them will attract more new users to TexShop, whether or not they later turn into power users. I would argue that this is good, if we wish to maximize the impact of TexShop.
>> 
>> -dave
>> 
>> And doesn't OS X provide a mechanism for this? Default macros, engines, etc. could go into /Library/Application Support/TeXShop/ and could easily be upgraded automatically; the current directory in ~/Library/TeXShop would be the user's responsibility, should they see the need. This is the way it is handled for AppleScripts, PreferencePanes, Screen Savers -- all sorts of things really.
>> 
>> Or am I missing the point?
> 
> No, you're not missing the larger point at all; but for reasons unknown to me, TeXShop deviates from the prescribed Apple model by completely blurring the distinction between "Application" and "User" with respect to many kinds of functionality, primarily Macros and Engines, but also command completion etc.  Because TeXShop allows us to change almost anything (good for power users) it copies all the macros, scripts, engines etc. into ~/Library/TeXShop from the application package itself.  There is no /Library/Application Support/TeXShop folder.
> 
> This has the result of being very non-transparent for most users, and has the unfortunate effect that new functionality in the form of macros, scripts or engines doesn't automatically show up when TeXShop is updated.  Of course, as the power users point out, they don't want upgrades messing with all their tweaking.  (I would generally consider myself a power user, but it took me quite a while to even realise that new functionality of this sort never showed up with TeXShop update; the default assumption would be that it *would* show up.)
> 
> Dick has proposed a solution, and this discussion is about its merits; I agree with you that sticking to the prescribed Apple method would make things more transparent for all users.  There are two problems with it as things stand now, though.  First, many established users have much invested in modified engines and macros and don't want this messed with.  Second, (and I think this is more fundamental, but probably solvable) there isn't a clear delineation between functionality that should be not modifiable by the user versus that which is.)  If we could reach some sort of consensus on this distinction, having new functionality show up automatically would be more possible.  
> 
> This is more or less what Dave Messerschmitt is proposing, and I agree with the basic sentiment (references to Einstein notwithstanding). 
> 
> While it's easy to take a particular solution that works, I think it's worthwhile to think of better solutions altogether and then decide whether the implementation of them is too difficult.  Having written a lot of code myself (although not much recently), I'm keenly aware of the programmer's bias towards solutions that are easy to program but end up like "Here's a fork, now go eat your soup". This is also what Dave is worried about w.r.t. open source software generally.
> 
> Alan
> 
> P.S.  Could those of you replying to things in this thread please not top-post.  It really does make following the conversation harder.  (Top posting is adding your comments on top of all the quoted material, rather than adding them in the appropriate parts of the commented material.)  Thanks.
> -- 
> Alan Munn
> amunn at gmx.com
> 
> 
> 
> 
> ----------- Please Consult the Following Before Posting -----------
> TeX FAQ: http://www.tex.ac.uk/faq
> List Reminders and Etiquette: http://email.esm.psu.edu/mac-tex/
> List Archive: http://tug.org/pipermail/macostex-archives/
> TeX on Mac OS X Website: http://mactex-wiki.tug.org/
> List Info: http://email.esm.psu.edu/mailman/listinfo/macosx-tex
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://email.esm.psu.edu/pipermail/macosx-tex/attachments/20100222/54f61223/attachment.html>