I agree with Erik. 

I would not perhaps mind if it will be added to the list of alternative 
editors in the workshop template, which currently says "Others editors 
that you can  use areNotepad++ or Sublime Text for Win; Text Wrangler
or Sublime Text for macOS; Gedit,Kate or Sublime Text for Linux (BTW,
we can now replace Text Wrangler by BBEdit). 

However, one of the Atom features that we should be aware is as such:
I have default Atom installation, and it automatically truncates trailing
spaces in the end of the line when it saves the file. So even opening and
saving a file with nano could change it. This is fine when a new file is
being created, but when one edits an existing file and makes a commit, then
the history will be polluted by normalising line ends mixed with actual
changes in the code. This is not a good practice. I haven't found where 
this can be changed in Atom's settings (but was not too persistent, since
I am usually using another editor).

So, I'd support staying with nano being the 1st choice at least for now.
It is useful at least in the two very relevant contexts that we teach:
when one runs a shell on a remote server and has to edit some file there,
and also when one writes a commit message.

We were teaching in St Andrews last week, and I was absolutely impressed 
that nano worked for all 20+ participants with all three kinds of OS
represented. I explained why we use nano for teaching, and recommended
that they may look onto more advanced editor in the future. But we also
configured git to use nano for composing commit messages, and as I've
said, this could be the genuine case when they will be using nano from
now on.

Best wishes
Alexander

Disclaimer:I use Atom only from time to time, and I had no time to study it 
deeper. 






> On 30 Mar 2017, at 14:54, Erik Bray <[email protected]> wrote:
> 
> On Thu, Mar 30, 2017 at 3:17 PM, Bennet Fauber <[email protected]> wrote:
>> I really do not mean to be a troll, here, but it seems to me that the
>> trend is to develop SWC/DC away from a coherently organized workshop
>> centered around the idea of creating a pipeline that is run using
>> scripts, invoked from a command line, and that is under version
>> control.  That is how I interpreted the original idea; perhaps
>> incorrectly.
>> 
>> It seems as though most lessons are now R Studio based.  Some Python
>> lessons may be Spyder based.  I'm pretty sure I seen much discussion
>> about GUI front-ends to Git.  If I were taking a workshop with Atom,
>> gitk, and R Studio, I would really have to wonder why there was a
>> shell component at all.
>> 
>> I think that in the past, one learned shell to move around, nano to
>> edit, then one used nano and the shell to create R or Python files,
>> which were run from the command line, and all of the code was under
>> Git control which was also run from the command line.  That scheme has
>> an internal coherence, it builds skill upon skill, and there is a
>> recognizable goal.
>> 
>> The lessons seem to be getting more and more independent and less and
>> less like parts of something bigger -- at least that's how I would see
>> it from a participants perspective and based on the anecdotes I have
>> from people who've been to recent camps.
>> 
>> There have been many discussions about individual lessons and far
>> fewer about connections among lessons, or so is my impression.  Is
>> optimizing each lesson separately really going to lead to a globally
>> optimized result?  What is the result that is desired?
>> 
>> I really don't want to start a firestorm, but I think it's good every
>> once in a while to step back and look at how the pieces fit together.
>> How does teaching someone the shell help them with Atom, or
>> vice-versa?  Would it be better to just drop the shell entirely and
>> create a full lesson on Atom?  The world does move on, and I'm just
>> missing the point, in which case ignore me. I'm really just trying to
>> give something to think about, as part of 'due diligence'.  If you
>> think Atom is the way to go, then you're definitely on the right track
>> with trialing in a lesson and seeing how it plays.
> 
> I sort of agree with this.  I have no idea even what Atom is and I
> ain't gonna learn it just so I can teach it.  Some might have said
> that about "git" once as well, but as least git is an actual useful
> skill to learn, whereas sitting someone in an editor more complex than
> notepad is just a massive distraction.
> 

_______________________________________________
Discuss mailing list
[email protected]
http://lists.software-carpentry.org/listinfo/discuss

Reply via email to