FLOSS Project Planets

A note from our fabulous DrupalCon Minneapolis program committee:

With a December 4, 2019 deadline we are one-third of the way through the DrupalCon Minneapolis 2020 session submission period. The program committee is thrilled with what we’ve seen so far, with many compelling sessions to review—from accessibility to Xdebug. If you aren’t one of the early submitters, however, we still need your voice! And we are here to support you.

As a reminder… next Wednesday (Oct 16) I’m giving a webinar on React+TypeScript+TDD in PyCharm. I’m doing some blog posts about material that will be covered.

See the first blog post for some background on this webinar and its topic.

Spotlight: Starting Testing

The first tutorial steps got us setup in the IDE, with a sample project generated and cleaned up. Now it’s time to learn React and TypeScript by…writing tests?

Indeed! This tutorial is trying to sell you on the idea that you’ll be more productive and happier writing and using your components from inside the IDE, instead of constantly heading over to the browser. For most of the steps in the tutorial, you do all of the learning, typing, and running from within a test, staying in the IDE and in the “flow”.

That’s the point of this tutorial step covering testing. Get you into a Jest run configuration, code on the left, tests on right, test runner at the bottom. We write some tests, “fail faster”, and get introduced to Jest and Enzyme.

Here’s the narrated video to go along with this tutorial step:

If you’re interested in more, here’s the entire tutorial. Hope to see you next week.

As you already know KDAB is the largest independent contributor to Qt code. Of course we didn’t get lazy and we’ve added a lot of cool stuff to Qt 5.14.

In this article I’m going to write about the super cool stuff that we’ve added to Qt 5.14 for Android.

Android multi arch build in one go

Folks, this is the biggest feature added to Qt on Android since I made the Qt on Android port! I dreamt on this change for a very loong time! I found that is possible to add such support to qmake by mistake :). I had to do some work on Windows (which is not my platform of choice) and there I found that debug and release builds are different on Windows, the makefiles generated by qmake will build twice your source files.

This was exactly what I needed to add multi abi for Android! A few days later I had a WIP patch and, with the help of The Qt Company people, we landed the change in Qt 5.14 alpha!

Let’s see what is new:

• First and foremost from Qt 5.14 there will be a single Qt for Android SDK. Same as the Android NDK, the Qt for Android SDK contains the libs & plugins built for all Android platforms (armv7a, arm64-v8a, x86, x86_64). If you’re building Qt from sources and you want to build only for e.g. arm architectures, you can filter them using the new -android-abis configure parameter: ./configure -android-abis armv7a,arm64-v8a -developer-build -xplatform android-clang -android-ndk /home/bogdan/android/ndk-bundle -android-sdk /home/bogdan/android
• If not specified otherwise, your application will be built by default for all these platforms in one go. You can filter which ABI(s) you want to build for using the ANDROID_ABIS qmake variable, this is useful while you develop your application, to cut the build time. Build only for arm64-v8a
  qmake ANDROID_ABIS="arm64-v8a"

  Build only for armv7a and arm64-v8a

  qmake ANDROID_ABIS="armeabi-v7a arm64-v8a"

Yes, we changed Qt Creator to make it easier to choose which platforms you want to build for, check the next image:

In order to support this super cool feature we had to change a few things:

• All the .so files produced by qmake are suffixed with the android abi. If you’re using Qt library/plugins classes you don’t need to take any actions, otherwise qmake sets QT_ARCH variable for the ABI you’re currently building, so you can use it to know which suffix you need to add e.g:
  # ... android: DEFINES += LIBS_SUFFIX='\\"_$${QT_ARCH}.so\\"' # ...

  Then you can use LIBS_SUFFIX macro in your srcs.

• Because on android we have only one libs folder level, we must rename all the [qml] plugins to make sure we don’t have any name clashes. We use the following naming scheme: lib + "plugin/path".replace('/','_') + {plugin_name} + _$${QT_ARCH}.so.

  If you have a plugin which uses ANDROID_LIB_DEPENDENCIES qmake variable make sure you use the previous naming scheme. Here https://codereview.qt-project.org/c/qt/qtgamepad/+/273676/2/src/gamepad/gamepad.pro you can see how we did it for Qt Gamepad module. Initially I did the renaming from androiddeployqt, but soon I found that this breaks the plugins debugging, as the gdb won’t find the renamed files on the Qt folders, and for me not being able to debug my precious plugins was unacceptable.

Android App Bundles (aab)

I’m going to tell you a secret, Android App Bundles were the main reason for doing the multi arch build in one go :). Without multi arch build in one go you can’t have aab, well at least not without a lot of work, pain and sorrow. Because I’m a happy, lazy person, I don’t like to work more than I must, therefore I had to find a solution to make our life easier. In Qt 5.14, it’s very easy to build an .aab file:

$ make aab

it’s all you need to run on a terminal to build it!

Same as above, I added a new option to Qt Creator to enable .aab packages with a single check box, see the following image:

Load Qt plugins directly from android libs folder

Since Qt 5.14, the Qt plugins were stored to android assets and then extracted to your home folder at the very first start. There are two problems with this approach:

• The very first startup time needed more time to extract all the files
• It occupies more disk space

Starting with 5.14, instead of bundling the plugins and QML resources in assets and extracting them on first start, Qt now creates an .rcc file and registers it before invoking the main function.

Other pretty nice changes

• Same as above, in Qt 5.14 you can easily create an apk from the command line: $ make apk

  is all you need to type on your terminal to create it.

• Reworked assets support – the new version fixes QDirIterators, also it lists all the files and folders.
• NDK r20+ is needed as I updated the clang mkspecs to follow https://android.googlesource.com/platform/ndk/+/ndk-release-r20/docs/BuildSystemMaintainers.md guide. With this change, let’s hope we’ll have less issues with newer NDK versions, as you probably noticed Google folks are restless and they are doing their best to break other tools from time to time :).
• Drop gcc support – this was a change that personally I didn’t like to do it, but I had to, mostly because it was quite challenging to support NDK r10e (the recommended NDK for gcc).
• Last but not least, an easy way to run tests on Android: $ make check

  It’s all you need. For more details and tweaks about it, you can come to my Qt World Summit presentation ;-).

• See more about KDAB Talks at Qt World Summit

The post Qt for Android better than ever before appeared first on KDAB.

This python module named PyUSB can be found at pypi website. [mythcat@desk scripts]$ pip3 install pyusb --user Collecting pyusb ... Successfully installed pyusb-1.0.2Let' see some usb device with lsusb command: [mythcat@desk scripts]$ lsusb Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 004:

Maria Espie Vidal, writer for Timedoctor.com, wrote a post for our blog in which she breaks down the role of an IT project manager. Check it out and gain a better understanding of the multifaceted job of IT project management.

READ MORE

The PyCon US Hatchery Program has become a fundamental part of how PyCon as a conference adapts to best serve the Python community as it grows and changes with time.

Initially we wanted to gauge community interest for this type of program, and since launching in 2018 we have learned more about what kind of events the community might propose. At the end of the inaugural program, we accepted the PyCon Charlas as our first Hatchery event which has grown into a permanent track offered at PyCon US.

PyCon US 2019 presented 3 new hatchery programs, Mentored Sprints, the Maintainers Summit, and the Art of Python. This year we are hoping to continue that growth, and are encouraging more organizers to propose their event ideas. If you are intrigued by the idea of proposing a hatchery event you may also want to look at Sumana Harihareswara's excellent write ups of both the motivation and execution of the Art of Python.

The long-term goals of this program are to support and grow sustainable programs that will become a recurring part of PyCon or find their place as a stand-alone event in the future. Programs that may be of specific temporal interest are also welcome, but will generally be given lower priority.

Our goal is to continue improving our community through inclusivity and diversity efforts. We hope that other international conferences, regional conferences, and local user groups can find inspiration in these efforts as they have in the past, adapting components of PyCon US into their own organizing.
Changes for 2020

• Updates to the application process have been implemented. All proposals will be submitted through us.pycon.org in order to standardize the format and content from each proposal.

• Improvements to how we support events with specific needs with respect to onsite support and room set-up.

Ready to submit your proposal?The Hatchery Program CFP is open now. You can find the details here. Submit Hatchery proposals online here. Proposals will be accepted through January 3, 2020 AoE.

KDE community has elected to finalize the transition to Wayland and embrace the future of desktop.

This entails making Plasma running smoothly under Wayland, but also making sure KDE Apps can run without bugs and missing features. It also means that we want to help the wider Wayland community to fill missing features and fix bugs.

I call App users and developers to try out their favorite app in Wayland and report the issue that may arise. and add wayland as keyword to the bug to keep track on those bugs.

And you don't need a wayland session to test an app, you can do it in wayland within a X session !

kwin_wayland # start an embed kwind_wayland

# In another terminal

gwenview --platform wayland # starts gwenview in the wayland session

We have a page listing how to fix a few pitfalls that applications may have in Wayland.

You can also test Plasma Wayland session of course and report the same way issues that may arise.

You can reach us at #kde-devel or #plasma in webchat.kde.org or freenode.

More information on the Wayland Goal page

Folks, it's not like the old days where there were just a couple of web frameworks for building apps with Python. These days there are many. One of those frameworks is the Masonite web framework created by Joseph Mancuso. Joseph is here today to tell us all about Masonite, what makes it special, it's core value proposition for web developers and much more.

I guess it is quite common to start the path towards programming by making games. I started with a simple guess the number on my dad’s zx81 back in the day. He must have written most of it, but I felt proud of the result, so I will claim that it was mine.

I’ve experimented with various ways to get my kids into programming. Everything from board games, online resources, scratch, building shitty robots, and so on. They get it, but it is hard to move on from the basics to being able to start from a clean sheet of paper and create something.

During the summer, I decided to look into the various options and tried using Unity and Godot. After a couple of experiments, I settled on using Godot. Partly because of its open nature, but also because as a tool, it does the job I need it to do just as well as Unity.

From my perspective, Godot is interesting, as it is a tool that is based around a visual editor. You do write code, but you add the code to the visual model, and not the other way around. This is somewhat backwards to me, as I come from a Qt background, but I’m positively surprised over how well it works.

Another positive surprise to me is that Godot also comes with export presets. These are pre-built run-time environments for common targets such as Windows, Linux/X11, Android, iOS, HTML5. Using these, it is trivial to cross compile and distribute your project – from any platform, to any platform. Very convenient. You can even build your own export presets.

When it comes to the not-so-good, Godot comes with its own language, GDScript. It does the job, and I quite enjoy working it it. You can use VisalScript as well, or C# with external tooling – you can also use GDNative to interface with the engine using your language of choice, but that is less straight forward. I do understand that there is some history that explains the choices, but to me it does feel like Python, without the huge library of Python libs.

Next up, I’ll blog about some of the games I’ve made, so prepare yourself for boardgames, classic game remakes as well as my humble experiments into VR.

I recently posted on getting TensorFlow 2.0 with GPU support running on Debian/sid. At that time I didn’t manage to get the tensorflow package for R running properly. It didn’t need much to get it running, though.

The biggest problem I faced was that the R/TensorFlow package recommends using install_tensorflow, which can use either auto, conda, virtualenv, or system (at least according to the linked web page). I didn’t want to set up neither a conda nor virtualenv environment, since TensorFlow was already installed, so I thought system would be correct, but then, I had it already installed. Anyway, the system option is gone and not accepted, but I still got errors. In particular because the code mentioned on the installation page is incorrect for TF2.0!

It turned out to be a simple error on my side – the default is to use the program python which in Debian is still Python2, while I have TF only installed for Python3. The magic incantation to fix that is use_python("/usr/bin/python3") and one is set.

So here is a full list of commands to get R/TensorFlow running on top of an already installed TensorFlow for Python3 (as usual either as root to be installed into /usr/local or as user to have a local installation):

devtools::install_github("rstudio/tensorflow")

And if you want to run some TF program:

library(tensorflow) use_python("/usr/bin/python3") tf$math$cumprod(1:5)

This gives lots of output but mentioning that it is running on my GPU.

At least for the (probably very short) time being this looks like a workable system. Now off to convert my TF1.N code to TF2.0.

Last month, I decided it was finally time to move a project I maintain from Github1 to another git hosting platform.

While polling other contributors (I proposed moving to gitlab.com), someone suggested moving to Sourcehut, a newish git hosting platform written and maintained by Drew DeVault. I've been following Drew's work for a while now and although I had read a few blog posts on Sourcehut's development, I had never really considered giving it a try. So I did!

Sourcehut is still in alpha and I'm expecting a lot of things to change in the future, but here's my quick review.

Things I like Sustainable FOSS

Sourcehut is 100% Free Software. Github is proprietary and I dislike Gitlab's Open Core business model.

Sourcehut's business model also seems sustainable to me, as it relies on people paying a monthly fee for the service. You'll need to pay if you want your code hosted on https://sr.ht once Sourcehut moves into beta. As I've written previously, I like that a lot.

In comparison, Gitlab is mainly funded by venture capital and I'm afraid of the long term repercussions this choice will have.

Continuous Integration

Continuous Integration is very important to me and I'm happy to say Sourcehut's CI is pretty good! Like Travis and Gitlab CI, you declare what needs to happen in a YAML file. The CI uses real virtual machines backed by QEMU, so you can run many different distros and CPU archs!

Even nicer, you can actually SSH into a failed CI job to debug things. In comparison, Gitlab CI's Interactive Web Terminal is ... web based and thus not as nice. Worse, it seems it's still somewhat buggy as Gitlab still hasn't enabled it on their gitlab.com instance.

Here's what the instructions to SSH into the CI look like when a job fails:

This build job failed. You may log into the failed build environment within 10 minutes to examine the results with the following command: ssh -t builds@foo.bar connect NUMBER

Sourcehut's CI is not as feature-rich or as flexible as Gitlab CI, but I feel it is more powerful then Gitlab CI's default docker executor. Folks that run integration tests or more complicated setups where Docker fails should definitely give it a try.

From the few tests I did, Sourcehut's CI is also pretty quick (it's definitely faster than Travis or Gitlab CI).

No JS

Although Sourcehut's web interface does bundle some Javascript, all features work without it. Three cheers for that!

Things I dislike Features division

I'm not sure I like the way features (the issue tracker, the CI builds, the git repository, the wikis, etc.) are subdivided in different subdomains.

For example, when you create a git repository on git.sr.ht, you only get a git repository. If you want an issue tracker for that git repository, you have to create one at todo.sr.ht with the same name. That issue tracker isn't visible from the git repository web interface.

That's the same for all the features. For example, you don't see the build status of a merged commit when you look at it. This design choice makes you feel like the different features aren't integrated to one another.

In comparison, Gitlab and Github use a more "centralised" approach: everything is centered around a central interface (your git repository) and it feels more natural to me.

Discoverability

I haven't seen a way to search sr.ht for things hosted there. That makes it hard to find repositories, issues or even the Sourcehut source code!

Merge Request workflow

I'm a sucker for the Merge Request workflow. I really like to have a big green button I can click on to merge things. I know some people prefer a more manual workflow that uses git merge and stuff, but I find that tiresome.

Sourcehut chose a workflow based on sending patches by email. It's neat since you can submit code without having an account. Sourcehut also provides mailing lists for projects, so people can send patches to a central place.

I find that workflow harder to work with, since to me it makes it more difficult to see what patches have been submitted. It also makes the review process more tedious, since the CI isn't ran automatically on email patches.

Summary

All in all, I don't think I'll be moving ISBG to Sourcehut (yet?). At the moment it doesn't quite feel as ready as I'd want it to be, and that's OK. Most of the things I disliked about the service can be fixed by some UI work and I'm sure people are already working on it.

Github was bought by MS for 7.5 billion USD and Gitlab is currently valued at 2.7 billion USD. It's not really fair to ask Sourcehut to fully compete just yet :)

With Sourcehut, Drew DeVault is fighting the good fight and I wish him the most resounding success. Who knows, maybe I'll really migrate to it in a few years!

1. Github is a proprietary service, has been bought by Microsoft and gosh darn do I hate Travis CI. ↩

Wing Pro 7 introduced an improved code warnings system that flags likely errors as you work on Python code, using both Wing's built-in static analysis system and (optionally) external code checkers like Pylint, pep8, and mypy. Likely problems are indicated on the editor and listed in the Code Warnings tool:

Examples of warnings that Wing might flag include syntax errors, indentation problems, uses of an undefined variable, imports that cannot be resolved, or variables that are set but never used.

Code warnings save development time because they help to identify errors before code is even run. New code is checked as you work, although Wing will wait until you have finished typing so that it doesn't warn about code that is still being entered.

Navigating Warnings

Clicking on warnings in the Code Warnings tool or pressing the Enter key in the list navigates to that warning in the editor, highlighting it briefly with a callout, as configured from the Editor > Callouts preferences group.

The code warnings icon appears in the top right of any editor that has some code warnings. This can be clicked in order to jump to selected warnings in the file.

When code warnings are displayed on the editor, hovering the mouse cursor over the indicator will display details for that warning in a tooltip, as shown above.

Configuration

The types of code warnings that Wing shows can be configured from the Configuration: Defaults page in the drop-down menu at the top of the Code Warnings tool. All the warnings Wing supports are documented in Warning Types. Some of these offer configuration options to control which variants of that type of warning will be shown:

Incorporating warnings found by external checkers like Pylint, pep8, and mypy is also done from this configuration page, as described previously in Using External Code Quality Checkers with Wing Pro 7

Disabling Warnings

Since all code checkers have only a limited understanding of what happens when code is actually run, they may show incorrect warnings. Wing allows you to disable warnings either for a single case, for an entire file, or for all files.

The quickest way to disable a warning is to press the red X icon that appears in the tooltips shown in the editor or in the currently selected item in the Code Warnings tool:

Wing disables most individual warnings only for the scope it appears in, so an identical problem in another scope will still be flagged. However, undefined attribute warnings are always disabled in all files where that attribute appears.

How it Works

When a warning is disabled, Wing adds a rule to the Configuration: Disabled Warnings page in the drop-down menu at the top of the Code Warnings tool:

Rules can be removed from here to reenable a warning, dragged between sections to control how widely the warning is being ignored, or edited by right-clicking in order to fine-tune the scope and nature of the rule.

For external checkers like Pylint, pep8, and mypy, warnings are disabled globally by the type of warning, making it relatively easy to develop a custom filter according to coding style and individual preference.

Resolving Imports

One thing to note here is that all the error checkers need some knowledge of your PYTHONPATH to trace down imports correctly. Often, no additional configuration is needed, but in cases where imports cannot be resolved you may need to add to the Python Path in Wing's Project Properties, from the Project menu.

Sharing Code Warnings Configurations

The current code warnings configuration, including all the warnings you have disabled, may be exported to the user settings area, or to a selected file from the Options menu in the Code Warnings tool. Projects may then share the configuration through the Use Configuration From item in the Code Warnings tool's Options menu:

The shared configuration file may be checked into revision control, so it can also be used by other developers working on your project.

That's it for now! We'll be back soon with more Wing Tips for Wing Python IDE.

Another month, another Armadillo upstream release! Hence a new RcppArmadillo release arrived on CRAN earlier today, and was just shipped to Debian as well. It brings a faster solve() method and other goodies. We also switched to the (awesome) tinytest unit test frameowrk, and Min Kim made the configure.ac script more portable for the benefit of NetBSD and other non-bash users; see below for more details. One again we ran two full sets of reverse-depends checks, no issues were found, and the packages was auto-admitted similarly at CRAN after less than two hours despite there being 665 reverse depends. Impressive stuff, so a big Thank You! as always to the CRAN team.

Armadillo is a powerful and expressive C++ template library for linear algebra aiming towards a good balance between speed and ease of use with a syntax deliberately close to a Matlab. RcppArmadillo integrates this library with the R environment and language–and is widely used by (currently) 665 other packages on CRAN.

Changes in RcppArmadillo version 0.9.800.1.0 (2019-10-09)

• Upgraded to Armadillo release 9.800 (Horizon Scraper)

  • faster solve() in default operation; iterative refinement is no longer applied by default; use solve_opts::refine to explicitly enable refinement

  • faster expmat()

  • faster handling of triangular matrices by rcond()

  • added .front() and .back()

  • added .is_trimatu() and .is_trimatl()

  • added .is_diagmat()

• The package now uses tinytest for unit tests (Dirk in #269).

• The configure.ac script is now more careful about shell portability (Min Kim in #270).

Courtesy of CRANberries, there is a diffstat report relative to previous release. More detailed information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

On Tuesday, October 15th, the Free Software Foundation (FSF) staff would like to meet you at a social event at Raleigh's [Whiskey Kitchen][1]!

Executive director John Sullivan, licensing and compliance manager Donald R. Robertson, III, copyright and licensing associate Craig Topham, and program manager ZoĂŤ Kooyman, will all be in Raleigh, NC on October 15th, in anticipation of this year's licensing seminar on GPL Enforcement and Legal Ethics.

We look forward to hosting this informal meetup to show our appreciation for your support of the FSF's work. We'll share some bites and drinks while giving you the opportunity to meet other FSF associate members and supporters while learning about what the FSF is currently working on. We are curious to hear your thoughts, and would love to answer any questions you may have.

• WHEN: Tuesday, October 15th from 6:30 pm - 8:30 pm PDT

• WHERE: [Whiskey Kitchen][1], 201 West Martin Street, Raleigh, NC 27601

• RSVP: Email campaigns@fsf.org

This is a social meetup for anyone who is interested in participating in the free software community or wants to learn more about the FSF. You don't have to be a current associate member to attend. We will be providing appetizers, including vegan/vegetarian friendly items. Your RSVP is helpful to us for notifying the venue of the amount of people to expect, but we still welcome people who have not planned ahead.

You are receiving this message because you have joined one of our email lists and have indicated that you live near the location of this event.

We look forward to meeting you in person!

The LibrePlanet call for sessions is open now and will be open until November 20 and we want to hear from you!

Speaking at a conference, and even submitting a proposal, can be intimidating or hard. Luckily, some great, experienced speakers are volunteering their time to help out during the CFS Office Hours.

Whether you want to propose a talk and want feedback on your idea, proposal wording, talk title, or just advice on how to deal with nerves, there are three office hours slots scheduled over the next few weeks.

Join #libreplanet on Freenode IRC on any of the following dates:

• Thursday, October 10th from 13:00 - 14:00 (EDT)
• Thursday, October 17th from 13:00 - 14:00 (EDT)
• Thursday, October 24th from 13:00 - 14:00 (EDT)
• Thursday, October 31st from 13:00 - 14:00 (EDT)
• Thursday, November 7th from 13:00 - 14:00 (EST)
• Thursday, November 14th from 13:00 - 14:00 (EST)

If you do not have an IRC client, you can log onto Freenode IRC here, and connect to the channel #libreplanet.

If you can't make an office hours meeting, feel free to email campaigns@fsf.org with questions.

There has been a lot of thoughtful debate about the Drupal project's contribution credit algorithm in recent weeks, and some great ideas have been proposed. In the meantime, however, we've also been monitoring concerns about gaming of the current algorithm. Making changes to the contribution credit algorithm must be done with care, because it has a significant impact on how we recognize contributions and also on the ecosystem of Drupal service providers. Today the Drupal Association engineering team deployed a quick tune-up to the contribution credit algorithm.

This change strengthens the existing multiplier which weighs issue credits based on the usage of the project. Issues on more highly used projects will now be weighted even higher, and those on lower usage projects will be weighted lower.

We're calling this a tune-up with good reason. This is not a fundamental update of the credit system; this is a small change to help resolve some recent issues with the current version of the algorithm.

Developing a true 'Contribution Credit 2.0' system is a much larger project, but one we're hoping to undertake soon.

In the meantime:

• If you have feedback on the small change we made today, you can find the issue here.
• If you'd like to propose new ideas about the next generation of the system, please do so in this issue.

As the community thinks about the contribution credit system, we encourage you to remember that there will always be a human element to recognizing contribution - and our goal should be a system that enables better interaction between project contributors.

Finding the right code editor for Python development can be tricky. Many developers explore numerous editors as they grow and learn. To choose the right code editor, you have to start by knowing which features are important to you. Then, you can try to find editors that have those features. One of the most feature-rich editors available is Emacs.

Emacs started in the mid-1970s as a set of macro extensions for a different code editor. It was adopted into the GNU project by Richard Stallman in the early 1980s, and GNU Emacs has been continuously maintained and developed ever since. To this day, GNU Emacs and the XEmacs variant are available on every major platform, and GNU Emacs continues to be a combatant in the Editor Wars.

In this tutorial, you’ll learn about using Emacs for Python development, including how to:

• Install Emacs on your selected platform
• Set up an Emacs initialization file to configure Emacs
• Build a basic Python configuration for Emacs
• Write Python code to explore Emacs capabilities
• Run and Test Python code in the Emacs environment
• Debug Python code using integrated Emacs tools
• Add source control functionality using Git

For this tutorial, you’ll use GNU Emacs 25 or later, although most of the techniques shown will work on older versions (and XEmacs) as well. You should have some experience developing in Python, and your machine should have a Python distribution already installed and ready to go.

Updates:

• 10/09/2019: Major update adding new code samples, updated package availability and info, basic tutorial, Jupyter walk-through, debugging walk-through, testing walk-through, and updated visuals.
• 11/03/2015: Initial tutorial published.

You can download all the files referenced in this tutorial at the link below:

Download Code: Click here to download the code you'll use to learn about Emacs for Python in this tutorial.

Installation and Basics

Before you can explore Emacs and all it has to offer a Python developer, you need to install it and learn some of the basics.

Installation

When you install Emacs, you have to consider your platform. This guide, provided by ErgoEmacs, provides everything you need to get up and running with a basic Emacs installation on Linux, Mac, or Windows.

Once the installation has finished, you can start Emacs:

You should be greeted with the default startup screen.

Basic Emacs

First, let’s go through a quick example to cover some basic Emacs for Python development. You’ll see how to edit a program using vanilla Emacs, and how much Python support is built into the program. With Emacs open, use the following steps to create a quick Python program:

1. Hit Ctrl+X Ctrl+F to open a new file.
2. Type sieve.py to name the file.
3. Hit Enter.
4. Emacs may ask you to confirm your choice. If so, then hit Enter again.

Now type the following code:

1 MAX_PRIME = 100 2 3 sieve = [True] * MAX_PRIME 4 for i in range(2, MAX_PRIME): 5 if sieve[i]: 6 print(i) 7 for j in range(i * i, MAX_PRIME, i): 8 sieve[j] = False

You may recognize this code as the Sieve of Eratosthenes, which finds all primes below a given maximum. As you type the code, you’ll notice:

• Emacs highlights variables and constants differently from Python keywords.
• Emacs indents lines following for and if statements automatically.
• Emacs changes the indentation to appropriate locations when you hit Tab on an indented line.
• Emacs highlights the opening bracket or parenthesis whenever you type a closing bracket or parenthesis.
• Emacs responds as expected to the arrow keys, as well as the Enter, Backspace, Del, Home, End, and Tab keys.

There are some odd key mappings in Emacs, however. If you try to paste code into Emacs, for instance, then you may find the standard Ctrl+V keystroke doesn’t work.

The easiest way to learn which keys do what in Emacs is to follow the built-in tutorial. You can access it by positioning the cursor over the words Emacs Tutorial on the Emacs start screen and pressing Enter, or by typing Ctrl+H T at any time thereafter. You’ll be greeted with the following passage:

Emacs commands generally involve the CONTROL key (sometimes labeled CTRL or CTL) or the META key (sometimes labeled EDIT or ALT). Rather than write that in full each time, we'll use the following abbreviations: C-<chr> means hold the CONTROL key while typing the character <chr> Thus, C-f would be: hold the CONTROL key and type f. M-<chr> means hold the META or EDIT or ALT key down while typing <chr>. If there is no META, EDIT or ALT key, instead press and release the ESC key and then type <chr>. We write <ESC> for the ESC key. Important Note: to end the Emacs session, type C-x C-c. (Two characters.) To quit a partially entered command, type C-g.

When you scan the text from the passage, you’ll see that Emacs keystrokes are shown in the Emacs documentation using the notation C-x C-s. This is the command to save the contents of the current buffer. This notation indicates that the Ctrl and X keys are pressed at the same time, followed by the Ctrl and S keys.

Note: In this tutorial, Emacs keystrokes are shown as Ctrl+X Ctrl+S.

Emacs uses some terminology that can be traced back to its text-based UNIX roots. Since these terms have different meanings now, it’s a good idea to review them, as you’ll be reading about them as the tutorial progresses:

• The window you see when you start Emacs is referred to as a frame. You can open as many Emacs frames as you wish, on as many monitors as you wish, and Emacs will track them all.

• The panes within each Emacs frame are referred to as windows. Emacs frames initially contain a single window, but you can open multiple windows in each frame, either manually or by running special commands.

• Within each window, the contents displayed are called a buffer. Buffers can contain the contents of files, the output of commands, the lists of menu options, or other items. Buffers are where you interact with Emacs.

• When Emacs needs your input, it asks in a special one-line area at the bottom of the currently active frame called the mini-buffer. If you ever find yourself there unexpectedly, then you can cancel whatever got you there with Ctrl+G.

Now that you’ve covered the basics, it’s time to start customizing and configuring Emacs for Python development!

Initialization File

One of the great benefits of Emacs is its powerful configuration options. The core of Emacs configuration is the initialization file, which is processed every time Emacs is started.

This file contains commands written in Emacs Lisp, which is executed every time Emacs is started. Don’t worry, though! You don’t need to know Lisp to use or customize Emacs. In this tutorial, you’ll find everything you need to get started. (After all, this is Real Python, not Real Lisp!)

On start-up, Emacs looks for the initialization file in three places:

1. First, it looks in your home user folder for the file .emacs.
2. If it’s not there, then Emacs looks in your home user folder for the file emacs.el.
3. Finally, if neither is found, then it looks in your home folder for .emacs.d/init.el.

The last option, .emacs.d/init.el, is the current recommended initialization file. However, if you’ve previously used and configured Emacs, then you may already have one of the other initialization files present. If so, then continue to use that file as you read this tutorial.

When you first install Emacs, there is no .emacs.d/init.el, but you can create this file fairly quickly. With the Emacs window open, follow these steps:

1. Hit Ctrl+X Ctrl+F.
2. Type ~/.emacs.d/init.el in the mini-buffer.
3. Hit Enter.
4. Emacs may ask you to confirm your choice. If so, then hit Enter again.

Let’s take a closer look at what’s happening here:

• You tell Emacs that you want to find and open a file with the keystrokes Ctrl+X Ctrl+F.

• You tell Emacs what file to open by giving it a path to the file. The path ~/.emacs.d/init.el has three parts:

  1. The leading tilde ~ is a shortcut to your home folder. On Linux and Mac machines, this is usually /home/<username>. On Windows machines, it’s the path specified in the HOME environment variable.
  2. The folder .emacs.d is where Emacs stores all its configuration information. You can use this folder to quickly set up Emacs on a new machine. To do so, copy the contents of this folder to your new machine, and Emacs is good to go!
  3. The file init.el is your initialization file.

• You tell Emacs, “Yes, I do want to create this new file.” (This step is required since the file doesn’t exist. Normally, Emacs will simply open the file specified.)

After Emacs creates the new file, it opens that file in a new buffer for you to edit. This action doesn’t actually create the file yet, though. You must save the blank file using Ctrl+X Ctrl+S to create it on disk.

Throughout this tutorial, you’ll see initialization code snippets that enable different features. Create the initialization file now if you want to follow along! You can also find the complete initialization file at the link below:

Download Code: Click here to download the code you'll use to learn about Emacs for Python in this tutorial.

Customization Packages

Now that you have an initialization file, you can add customization options to tailor Emacs for Python development. There are a few ways you can customize Emacs, but the one with the fewest steps is adding Emacs packages. These come from a variety of sources, but the primary package repository is MELPA, or the Milkypostman’s Emacs Lisp Package Archive.

Think of MELPA as PyPI for Emacs packages. Everything you need and will use in this tutorial can be found there. To begin using it, expand the code block below and copy the configuration code to your init.el file:

init.el Show/Hide

1 ;; .emacs.d/init.el 2 3 ;; =================================== 4 ;; MELPA Package Support 5 ;; =================================== 6 ;; Enables basic packaging support 7 (require 'package) 8 9 ;; Adds the Melpa archive to the list of available repositories 10 (add-to-list 'package-archives 11 '("melpa" . "http://melpa.org/packages/") t) 12 13 ;; Initializes the package infrastructure 14 (package-initialize) 15 16 ;; If there are no archived package contents, refresh them 17 (when (not package-archive-contents) 18 (package-refresh-contents)) 19 20 ;; Installs packages 21 ;; 22 ;; myPackages contains a list of package names 23 (defvar myPackages 24 '(better-defaults ;; Set up some better Emacs defaults 25 material-theme ;; Theme 26 ) 27 ) 28 29 ;; Scans the list in myPackages 30 ;; If the package listed is not already installed, install it 31 (mapc #'(lambda (package) 32 (unless (package-installed-p package) 33 (package-install package))) 34 myPackages) 35 36 ;; =================================== 37 ;; Basic Customization 38 ;; =================================== 39 40 (setq inhibit-startup-message t) ;; Hide the startup message 41 (load-theme 'material t) ;; Load material theme 42 (global-linum-mode t) ;; Enable line numbers globally 43 44 ;; User-Defined init.el ends here

As you read through the code, you’ll see that init.el is broken into sections. Each section is separated by comment blocks that begin with two semicolons (;;). The first section is titled MELPA Package Support:

1 ;; .emacs.d/init.el 2 3 ;; =================================== 4 ;; MELPA Package Support 5 ;; =================================== 6 ;; Enables basic packaging support 7 (require 'package) 8 9 ;; Adds the Melpa archive to the list of available repositories 10 (add-to-list 'package-archives 11 '("melpa" . "http://melpa.org/packages/") t) 12 13 ;; Initializes the package infrastructure 14 (package-initialize) 15 16 ;; If there are no archived package contents, refresh them 17 (when (not package-archive-contents) 18 (package-refresh-contents))

This section begins by setting up the packaging infrastructure:

• Line 7 tells Emacs to use packages.
• Lines 10 and 11 add the MELPA archive to the list of package sources.
• Line 14 initializes the packaging system.
• Lines 17 and 18 build the current package content list if it doesn’t already exist.

The first section continues from line 20:

20 ;; Installs packages 21 ;; 22 ;; myPackages contains a list of package names 23 (defvar myPackages 24 '(better-defaults ;; Set up some better Emacs defaults 25 material-theme ;; Theme 26 ) 27 ) 28 29 ;; Scans the list in myPackages 30 ;; If the package listed is not already installed, install it 31 (mapc #'(lambda (package) 32 (unless (package-installed-p package) 33 (package-install package))) 34 myPackages)

At this point, you’re all set to programmatically install Emacs packages:

• Lines 23 to 27 define a list of package names to install. You’ll add more packages as you progress through the tutorial:
  • Line 24 adds better-defaults. This is a collection of minor changes to the Emacs defaults that make it more user-friendly. It’s also a great base for further customization.
  • Line 25 adds the material-theme package, which is a nice dark style found in other environments.
• Lines 31 to 34 traverse the list and install any packages that are not already installed.

Note: You don’t need to use the Material theme. There are many different Emacs themes available on MELPA for you to choose from. Pick one that suits your style!

After you install your packages, you can move on to the section titled Basic Customization:

36 ;; =================================== 37 ;; Basic Customization 38 ;; =================================== 39 40 (setq inhibit-startup-message t) ;; Hide the startup message 41 (load-theme 'material t) ;; Load material theme 42 (global-linum-mode t) ;; Enable line numbers globally 43 44 ;; User-Defined init.el ends here

Here, you add a few other customizations:

• Line 40 disables the initial Emacs screen containing the tutorial information. You may want to leave this commented out by using a double semicolon (;;) until you’re more comfortable with Emacs.
• Line 41 loads and activates the Material theme. If you want to install a different theme, then use its name here instead. You can also comment out this line to use the default Emacs theme.
• Line 42 displays line numbers in every buffer.

Now that you have a complete basic configuration file in place, you can save the file using Ctrl+X Ctrl+S. Then, close and restart Emacs to see the changes.

The first time Emacs runs with these options, it may take a few seconds to start as it sets up the packaging infrastructure. When that’s finished, you’ll see that your Emacs window looks a bit different:

After the restart, Emacs skipped the initial screen and instead opened the last active file. The Material theme is applied, and line numbers have been added to the buffer.

Note: You can add packages interactively after the packaging infrastructure is set up. Hit Alt+X, then type package-show-package-list to see all the packages available to install in Emacs. As of this writing, there are over 4300 available.

With the list of packages visible, you can:

• Quickly filter the list by package name by hitting F.
• View the details of any package by clicking its name.
• Install the package from the package view by clicking the Install link.
• Close the package list using Q.

Emacs for Python Development With elpy

Emacs is ready out of the box to edit Python code. The library file python.el provides python-mode, which enables basic indentation and syntax highlighting support. However, this built-in package doesn’t provide much else. To properly compete with Python-specific IDEs (Integrated Development Environments), you’ll add more capabilities.

The elpy package (Emacs Lisp Python Environment) provides a near-complete set of Python IDE features, including:

• Automatic indentation
• Syntax highlighting
• Auto completion
• Syntax checking
• Python REPL integration
• Virtual environment support

To install and enable elpy, you add the package to your Emacs configuration. The following change to init.el will do the trick:

23 (defvar myPackages 24 '(better-defaults ;; Set up some better Emacs defaults 25 elpy ;; Emacs Lisp Python Environment 26 material-theme ;; Theme 27 ) 28 )

Once elpy is installed, you need to enable it. Add the following code just before the end of your init.el file:

45 ;; ==================================== 46 ;; Development Setup 47 ;; ==================================== 48 ;; Enable elpy 49 (elpy-enable) 50 51 ;; User-Defined init.el ends here

You now have a new section titled Development Setup. Line 49 enables elpy.

Note: Unfortunately, Emacs will only read the contents of the initialization file once when it starts. If you make any changes to it, then the easiest and safest way to load them is to restart Emacs.

To see the new mode in action, go back to the Sieve of Eratosthenes code you entered earlier. Create a new Python file and retype the Sieve code directly:

1 MAX_PRIME = 100 2 3 sieve = [True] * MAX_PRIME 4 for i as range(2, MAX_PRIME): 5 if sieve[i]: 6 print(i) 7 for j in range(i*i, MAX_PRIME, i): 8 sieve[j] = False

Note the intentional syntax error on line 4.

This is what your Python file would look like in Emacs:

Auto-indentation and keyword highlighting still work as before. However, you should also see an error indicator on line 4:

This error indicator pops up in the for loop when you typed as instead of in.

Correct that error, then type Ctrl+C Ctrl+C while in the Python buffer to run the file without leaving Emacs:

When you use this command, Emacs will do the following:

1. Create a new buffer named *Python*
2. Open your Python interpreter and connect it to that buffer
3. Create a new window under your current code window to display the buffer
4. Send the code to the interpreter to execute

You can scroll through the *Python* buffer to see which interpreter was run and how the code was started. You can even type commands at the prompt (>>>) at the bottom.

Often, you’ll want to execute your code in a virtual environment using the interpreter and packages specified for that environment. Fortunately, elpy includes the pyvenv package, which provides built-in support for virtual environments.

To use an existing virtual environment in Emacs, type Alt+X pyvenv-workon. Emacs will ask for the name of the virtual environment to use and activate it. You can deactivate the current virtual environment with Alt+X pyvenv-deactivate. You can also access this functionality from the Emacs menu, under Virtual Envs.

You can also configure elpy from within Emacs. Type Alt+X elpy-config to display the following dialog:

You should see valuable debugging information, as well as options to configure elpy.

Now you’ve put all of the basics of using Emacs with Python in place. Time to put some icing on this cake!

Additional Python Language Features

In addition to all of the basic IDE features described above, there are other syntax features you can use with Emacs for Python development. In this tutorial, you’ll cover these three:

1. Syntax checking with flycheck
2. Code formatting with PEP 8 and black
3. Integration with Jupyter and IPython

This is not an exhaustive list, however! Feel free to play around with Emacs and Python to see what other syntax features you can discover.

Syntax Checking

By default, elpy uses a syntax-checking package called flymake. While flymake is built into Emacs, it only has native support four languages, and it requires significant effort to be able to support new languages.

Luckily, there is a newer and more complete solution available! The syntax-checking package flycheck supports real-time syntax checking in over 50 languages and is designed to be quickly configured for new languages. You can read about the differences between flymake and flycheck in the documentation.

You can quickly switch elpy to use flycheck instead of flymake. First, add flycheck to your init.el:

23 (defvar myPackages 24 '(better-defaults ;; Set up some better Emacs defaults 25 elpy ;; Emacs Lisp Python Environment 26 flycheck ;; On the fly syntax checking 27 material-theme ;; Theme 28 ) 29 )

flycheck will now be installed with the other packages.

Then, add the following lines in the Development Setup section:

46 ;; ==================================== 47 ;; Development Setup 48 ;; ==================================== 49 ;; Enable elpy 50 (elpy-enable) 51 52 ;; Enable Flycheck 53 (when (require 'flycheck nil t) 54 (setq elpy-modules (delq 'elpy-module-flymake elpy-modules)) 55 (add-hook 'elpy-mode-hook 'flycheck-mode))

This will enable flycheck when Emacs runs your initialization file. Now you’ll see real-time syntax feedback whenever you use Emacs for Python code editing:

Notice the syntax reminder for range(), which appears at the bottom of the window as you type.

Code Formatting

Love it or hate it, PEP 8 is here to stay. If you want to follow all or some of the standards, then you’ll probably want an automated way to do so. Two popular solutions are autopep8 and black. These code formatting tools must be installed in your Python environment before they can be used. To learn more about how to install an auto-formatter, check out How to Write Beautiful Python Code With PEP 8.

Once the auto-formatter is available, you can install the proper Emacs package to enable it:

• py-autopep8 connects autopep8 to Emacs.
• blacken enables black to run from within Emacs.

You only need to install one of these in Emacs. To do so, add one of the following highlighted lines to your init.el:

23 (defvar myPackages 24 '(better-defaults ;; Set up some better Emacs defaults 25 elpy ;; Emacs Lisp Python Environment 26 flycheck ;; On the fly syntax checking 27 py-autopep8 ;; Run autopep8 on save 28 blacken ;; Black formatting on save 29 material-theme ;; Theme 30 ) 31 )

If you’re using black, then you’re done! elpy recognizes the blacken package and will enable it automatically.

If you’re using autopep8, however, then you’ll need to enable the formatter in the Development Setup section:

48 ;; ==================================== 49 ;; Development Setup 50 ;; ==================================== 51 ;; Enable elpy 52 (elpy-enable) 53 54 ;; Enable Flycheck 55 (when (require 'flycheck nil t) 56 (setq elpy-modules (delq 'elpy-module-flymake elpy-modules)) 57 (add-hook 'elpy-mode-hook 'flycheck-mode)) 58 59 ;; Enable autopep8 60 (require 'py-autopep8) 61 (add-hook 'elpy-mode-hook 'py-autopep8-enable-on-save) 62 63 ;; User-Defined init.el ends here

Now, every time you save your Python code, the buffer is automatically formatted and saved, and the contents reloaded. You can see how this works with some badly formatted Sieve code and the black formatter:

You can see that after the file is saved, it’s reloaded in the buffer with the proper black formatting applied.

Integration With Jupyter and IPython

Emacs can also work with Jupyter Notebooks and the IPython REPL. If you don’t already have Jupyter installed, then check out Jupyter Notebook: An Introduction. Once Jupyter is ready to go, add the following lines to your init.el after the call to enable elpy:

48 ;; ==================================== 49 ;; Development Setup 50 ;; ==================================== 51 ;; Enable elpy 52 (elpy-enable) 53 54 ;; Use IPython for REPL 55 (setq python-shell-interpreter "jupyter" 56 python-shell-interpreter-args "console --simple-prompt" 57 python-shell-prompt-detect-failure-warning nil) 58 (add-to-list 'python-shell-completion-native-disabled-interpreters 59 "jupyter") 60 61 ;; Enable Flycheck 62 (when (require 'flycheck nil t) 63 (setq elpy-modules (delq 'elpy-module-flymake elpy-modules)) 64 (add-hook 'elpy-mode-hook 'flycheck-mode))

This will update Emacs to use IPython rather than the standard Python REPL. Now when you run your code with Ctrl+C Ctrl+C, you’ll see the IPython REPL:

While this is pretty useful on its own, the real magic is in the Jupyter Notebook integration. As always, you need to add a bit of configuration to enable everything. The ein package enables an IPython Notebook client in Emacs. You can add it to your init.el like so:

23 (defvar myPackages 24 '(better-defaults ;; Set up some better Emacs defaults 25 elpy ;; Emacs Lisp Python Environment 26 flycheck ;; On the fly syntax checking 27 py-autopep8 ;; Run autopep8 on save 28 blacken ;; Black formatting on save 29 ein ;; Emacs IPython Notebook 30 material-theme ;; Theme 31 ) 32 )

You can now start a Jupyter server and work with Notebooks from within Emacs.

To start the server, use the command Alt+X ein:jupyter-server-start. Then provide a folder in which to run the server. You’ll see a new buffer showing the Jupyter Notebooks available in the folder selected:

From here you can create a new Notebook with a selected kernel by clicking New Notebook, or open an existing Notebook from the list at the bottom by clicking Open:

You can complete the exact same task by typing Ctrl+X Ctrl+F, and then typing Ctrl+C Ctrl+Z. This will open the Jupyter Notebook directly in Emacs as a file.

With a Notebook open, you can:

• Move around the Notebook cells using the arrow keys
• Add a new cell above the current cell using Ctrl+A
• Add a new cell below the current cell using Ctrl+B
• Execute new cells using either Ctrl+C Ctrl+C or Alt+Enter

Here’s an example of how to move around a Notebook, add a new cell, and execute it:

You can save your work using Ctrl+X Ctrl+S.

When you’re done working in your notebook, you can close it using Ctrl+C Ctrl+Shift+3. You can stop the Jupyter server completely by hitting Alt+X ein:jupyter-server-stop. Emacs will ask you if you want to kill the server and close all open Notebooks.

Of course, this is just the tip of the Jupyter iceberg! You can explore everything the ein package can do in the documentation.

Testing Support

Do you write perfect code that has no side-effects and performs well under all conditions? Of course… not! If this sounds like you, though, then you’re free to skip ahead a bit. But for most developers, testing code is a requirement.

elpy provides extensive support for running tests, including support for:

• unittest
• nose
• pytest
• green
• Twisted’s trial
• Django

To demonstrate the testing capabilities, the code for this tutorial includes a version of Edsger Dijkstra’s shunting yard algorithm. This algorithm parses mathematical equations that are written using infix notation. You can download the code at the link below:

Download Code: Click here to download the code you'll use to learn about Emacs for Python in this tutorial.

To start, let’s get a more complete picture of the project by viewing the project folder. You can open a folder in Emacs using Ctrl+X D. Next, you’ll display two windows in the same frame by splitting the frame vertically with Ctrl+X 3. Finally, you navigate to the test file in the left window, and click on it to open it in the right window:

The test file expr_test.py is a basic unittest file that contains a single test case with six tests. To run the test case, type Ctrl+C Ctrl+T:

The results are displayed in the left window. Notice how all six tests were run. You can run a single test in a test file by putting the cursor in that test before typing Ctrl+C Ctrl+T.

Debugging Support

When tests fail, you’ll need to delve into the code to figure out why. The built-in python-mode allows you to use Emacs for Python code debugging with pdb. For an introduction to pdb, check out Python Debugging with Pdb.

Here’s how to use pdb in Emacs:

1. Open the debug-example.py file in the PyEval project.
2. Type Alt+X pdb to start the Python debugger.
3. Type debug-example.py Enter to run the file under the debugger.

Once it’s running, pdb will split the frame horizontally and open itself in a window above the file you’re debugging:

All debuggers in Emacs run as part of the Grand Unified Debugger library, also called the GUD. This library provides a consistent interface for debugging all supported languages. The name of the buffer created, *gud-debug-example.py*, shows that the debug window was created by the GUD.

The GUD also connects pdb to the actual source file in the bottom window, which tracks your current location. Let’s step through this code to see how that works:

You can step through code in pdb using one of two keys:

1. S steps into other functions.
2. N steps over other functions.

You’ll see the cursor move in the lower source window to keep track of the execution point. As you follow function calls, pdb opens local files as required to keep you moving forward.

Git Support

No modern IDE would be complete without support for source control. While numerous source control options exist, it’s a fair bet that most programmers are using Git. If you’re not using source control, or need to learn more about Git, then check out Introduction to Git and GitHub for Python developers.

In Emacs, source control support is provided by the magit package. You install magit by listing it in your init.el file:

23 (defvar myPackages 24 '(better-defaults ;; Set up some better Emacs defaults 25 elpy ;; Emacs Lisp Python Environment 26 ein ;; Emacs iPython Notebook 27 flycheck ;; On the fly syntax checking 28 py-autopep8 ;; Run autopep8 on save 29 blacken ;; Black formatting on save 30 magit ;; Git integration 31 material-theme ;; Theme 32 ) 33 )

After you restart Emacs, magit will be ready to use.

Let’s take a look at an example. Open any of the files in the PyEval folder, then type Alt+X magit-status. You’ll see the following appear:

When activated, magit splits the Emacs frame and displays its status buffer in the lower window. This snapshot lists the staged, unstaged, untracked, and any other files in your repo folder.

Most of the interaction you do with magit will be in this status buffer. For example, you can:

• Move between sections in the status buffer using P for Previous and N for Next
• Expand or collapse a section using Tab
• Stage changes using S
• Unstage changes using U
• Refresh the contents of the status buffer using G

Once a change is staged, you commit it using C. You’ll be presented with a variety of commit variations. For a normal commit, hit C again. You’ll see two new buffers appear:

1. The lower window contains the COMMIT_EDITMSG buffer, which is where you add your commit message.
2. The upper window contains the magit-diff buffer, which displays the changes you are committing.

After entering your commit message, type Ctrl+C Ctrl+C to commit the changes:

You may have noticed the top of the status buffer displaying both the Head (local) and Merge (remote) branches. This allows you to push your changes to the remote branch quickly.

Look in the status buffer under Unmerged into origin/master and find the changes you want to push. Then, hit Shift+P to open the push options, and P to push the changes:

Out of the box, magit will talk to GitHub and GitLab, as well as a host of other source control tools. For more info on magit and its capabilities, check out the full documentation.

Additional Emacs Modes

One of the major benefits of using Emacs over a Python-specific IDE is the ability to work in other languages. As a developer, you might have to work with Python, Golang, JavaScript, Markdown, JSON, shell scripts, and more, all in a single day! Having complex and complete support for all of these languages in a single code editor will increase your efficiency.

There are tons of example Emacs initialization files available for you to review and use to build your own configuration. One of the best sources is GitHub. A GitHub search for emacs.d turns up a plethora of options for you to sift through.

Alternatives

Of course, Emacs is only one of several editors available for Python developers. If you’re interested in alternatives, then check out:

• Setting Up Sublime Text 3 for Full Stack Python Development
• Thonny: The Beginner-Friendly Python Editor
• Python Development in Visual Studio Code
• VIM and Python — A Match Made in Heaven
• PyCharm for Production Python Development (Guide)

Conclusion

As one of the most feature-rich editors available, Emacs is great for Python programmers. Available on every major platform, Emacs is extremely customizable and adaptable to many different tasks.

Now you can:

• Install Emacs on your selected platform
• Set up an Emacs initialization file to configure Emacs
• Build a basic Python configuration for Emacs
• Write Python code to explore Emacs capabilities
• Run and Test Python code in the Emacs environment
• Debug Python code using integrated Emacs tools
• Add source control functionality using Git

Give Emacs a try on your next Python project! You can download all the files referenced in this tutorial at the link below:

Download Code: Click here to download the code you'll use to learn about Emacs for Python in this tutorial.

[ Improve Your Python With 🐍 Python Tricks 💌 – Get a short & sweet Python Trick delivered to your inbox every couple of days. >> Click here to learn more and see examples ]

So, finally it seems like, after crossing the deadline by a couple months, Magnetic Lasso is going to get merged, as Boud told me. Lets see how many more weeks it takes, so presumably it is complete feature wise but who knows from where a bug might pop up.

Welcome to WordPress. This is your first post. Edit or delete it, then start writing!