A couple of weeks ago, I asked what new functions we could add to our smartphones. Kontra has a suggestion:
Which would you prefer to have in iPhone 13 Pro cameras?
a) 4X telephoto
b) Spectrometer (for instant display of body fat, freshness/nutritional value of food, skin moisture, alcohol % in drinks, etc)
— Kontra (@counternotions) October 31, 2019
A spectrometer would be nice. If nothing else, it would finally satisfy the yearning that many of us have for a real tricorder.
This is my third post on the burning issue of whether light-mode or dark-mode is better and, more importantly, what do we mean by “better”. Given the frequency of my revisiting the matter, you might think it’s something I care deeply about or are obsessed with. The truth is, though, I don’t really care one way or the other. I’ve always considered it an aesthetic choice that reasonable people can differ about, even if I did find it odd that some—okay, most—people prefer dark mode.
It wasn’t until the hipsters adopted the issue and tried to cast all us right-thinking light-mode people into the darkness that I ever thought about the matter in other than an idle way. Now, of course, the battle is joined.
Of my previous two posts, the first concentrated on research showing that light-mode is actually easier to read and “more natural” than dark-mode, while the second reported on Andrew Couts’ theory that the whole thing is really a fashion statement by the dark-mode adherents.
Over at Fast Company, they have an article that asks if dark-mode is really better for you. The article is more neutral than the other two and doesn’t energetically assert one position or the other but it does note that the research shows that light-mode is easier to read. On the other hand, some applications really are bettered served with dark-mode and the article mentions some of those and explains why dark-mode works better for them. Their conclusion, like Couts’, is that it’s mostly a matter of fashion.
I’ve noticed a lot of Reddit posts and tweets recently that refer to Emacs packages1 as “plugins.” Perhaps I’m growing increasingly cantankerous in my old age or maybe I’m just tired and grumpy—waving your cane at those kids on your lawn can be surprisingly enervating—but this always sets my teeth on edge.
I think of plugins as something those other editors have: some code that uses a limited API provided by the editor’s author that can perform some predetermined, well defined tasks. Emacs isn’t like that. You can extend its code or even replace its code. The things we call packages are actually first class objects indistinguishable from the rest of Emacs except for the artificial distinction that they’re not part of “core Emacs.” They don’t depend on any extension mechanism other than the same Lisp interpreter used by the rest of Emacs.
This is, of course, what I refer to as a “first-world problem.” It’s simply a matter of terminology—like the window/frame distinction that often confuses n00bs—and doesn’t matter very much. Still, we insist on the window/frame distinction and I see no reason why this should be different. What do you think? Am I wrong to insist on the distinction? It doesn’t, after all, cause any confusion like misusing “window” when you mean “frame” but it does obscure one of the most important features and strengths of Emacs: true extensibility.
I’m going to abuse terminology just a bit and refer to even code that’s contained in a single file and not packaged up for ELPA as a “package.”
Many of you know that I consider Abelson’s & Sussman’s Structure and Interpretation of Computer Programs (SICP) one of the best Computer Science books ever written. Although I read it late in my career, it opened my eyes to a new way of looking at things and I learned a huge amount from it. It’s one of those books that everyone working in programming absolutely must read.
Over at Corecursive, Adam Gordon Bell has a really interesting podcast interview with Hal Abelson. In addition to being an MIT Professor and one of the authors of SICP, Abelson also cofounded the FSF and was a founding director Creative Commons. He’s an interesting guy with a lot to say.
Much of the interview was concerned with the point of view of SICP and what Abelson and Sussman were trying to accomplish by writing it. In a way, the book has been a victim of its foresight and success. These days, the notion of abstraction and how to accomplish it with programming languages are accepted dogma and SICP can seem like old hat. Back when SICP was being written, though, it was new way of thinking about and teaching programming. Abelson also notes that one of the main lessons in the book is that writing a program to solve a problem is best thought of as designing a language to solve the problem. That way you avoid the problem of writing a program that provides too narrow a solution. Abelson spends some time on this idea and it’s definitely worth paying attention to.
This is a great interview with a lot interesting history and insight. It’s just short of 56 and a half minutes so you’ll have to plan ahead but it’s well worth your time.
If you’re an Emacs user who has an iPhone or iPad, I’d be willing to bet that you’ve been yearning for an implementation of Emacs on iOS/iPadOS. I know I have. Sadly, I’ve haven’t seen any movement in that direction. What we do have, though, are various projects to bring Org-mode to our Mobile devices.
For many people, that’s probably what they really want. No one, I’m sure, is wishing they could edit files on their iPhones or Android-based phones. A better case can be made for Emacs on the iPad but, really, what many (most?) people want is a way of viewing their agenda, capturing new data or tasks, and closing out completed tasks on their phones.
The two projects that I hear the most about are Orgzly for Android and Beorg for the iPhone. Now there’s a third contender: Organice. Alain M. Lafon, who gave that excellent talk last year on Playing Emacs Like an Instrument, has another nice presentation, this time on using Org mode from the browser and smartphone. Organice is meant to be an implementation of Org-mode that’s independent of Emacs. You can use it on your desktop/laptop in the browser or you can use it on your mobile phone. It works with both iPhone and Android phones.
This looks like a really interesting project that may go a long way toward scratching that itch that all Org-mode users have: a desire to take Org with them when they’re away from their computers. Organice’s introduction gives everybody at least two choices for Org-mode on their phones. It also gives those poor souls not using Emacs access to one of our editor’s killer features.
If you’re a Gmail user, the past is coming due. After years of what seemed like an infinite amount of free storage, Google is starting to charge for more space. Many people are surprised by the move. They shouldn’t be. They’ve been warned repeatedly about Google but just assumed everything would be fine despite Google’s record of changing or sunsetting popular services. Karl Voit, for one, doesn’t have a lot of sympathy for those surprised by the move.
The truth, of course, is that Gmail was never free. You paid for it by allowing Google to read your mail, build a profile of your likes and dislikes, and target you with annoying ads. For millions of people, that seemed like a fair deal so Gmail prospered to the point that many other email services were forced out of business.
Now Google wants to back out of its end of the deal. Since they are by far the dominant email provider, they apparently started thinking that they could squeeze a few more dollars out of those poor souls still using it. Of course, they’ll still be scanning your emails and collecting your data but now you’ll have to pay them to do it.
My advice remains what it has been for many years: if you’re using a Google service, stop. That’s especially true of the services that involve your data. Stop using Gmail and for goodness sake stop using Google documents and related apps. That’s advice I’ve given many times before and I don’t expect it will be heeded this time either. Some people, it seems, enjoy being spied on so much that they’re willing to pay for it.
Mike Zamansky is working on a Web app. As with most such apps, it has a front end that provides the UI and gathers requests for the server, and a back end that runs on the server and does the “computations”. Apps like that can be tricky to develop because it’s hard to write the front end without some way of feeding it data from the server. On the other hand, it’s hard to communicate with the server without a front end.
There are plenty of workarounds of various utility but Zamansky decided to try out restclient in the 60th video of his Using Emacs Series. Using restclient is a win because you don’t have to leave your development environment and there’s very little cutting and pasting between screens. It’s a nice tool. You can type in, say, a GET request and it will send it to the server, show you what displayable data comes back, and let’s you see the transaction metadata such as the return status.
I mostly concern myself with server-side applications so I don’t have much chance to use something like restclient but I’ve been intrigued with it since I saw Magnar Sveen’s Emacs Rocks! video about restclient in 2014. If you have a need to communicate with a server interactively, be sure to watch both Sveen’s and Zamansky’s videos. They’re both entertaining and informative. The Emacs Rocks! video is 2 minutes, 23 seconds and Zamansky’s is 14 minutes, 36 seconds. They’re well worth the time to watch and may show you a way to save a lot of development time and effort.
UPDATE : Clarified the front-end/back-end relationship a bit.
I’m a little behind today so let’s have another Red Meat Friday. For all you OO lovers and haters out there, Kontra has this offering:
Rob Pike (of Unix, UTF-8, Go fame): “object-oriented design is the roman numerals of computing”
Edsger Dijkstra: “object-oriented programming is an exceptionally bad idea which could only have originated in California”
(Just sayin’. :)
— Kontra (@counternotions) October 23, 2019
Just a quick update on my experience with macOS Catalina and Emacs. Last week, I wrote that after not reading about any significant problems with Emacs on Catalina, I upgraded my laptop. I haven’t seen any problems with Emacs as a result of the update. Quite the opposite. Emacs now seems snappier in general and it’s definitely faster for operations that involve shelling out to the operating system.
For example, before when I followed a URL link from an Org file, there was a significant delay. That started happening when I upgraded to Mojave. With the upgrade to Catalina, that delay is gone and everything is back to being nearly instantaneous. That’s a very welcome change.
The feeling that Emacs is snappier in general is more subjective but I do think things have speeded up a bit. Perhaps that’s wishful thinking but I guess it doesn’t matter. Seeming to be snappier is just as good as being snappier since it’s a matter of perception.
The takeaway is that there doesn’t seem to be any reason not to update to Catalina as far as Emacs is concerned. The biggest problem people are having with Catalina appears to be that 32 bit applications no longer work just as Apple warned us they wouldn’t. If you are absolutely dependent on an old 32 bit app, you may want to hold off upgrading but 32 bit support is never coming back so you’re going to have to make some arrangements sooner or later.
Marcin Borkowski has a really handy tip that explains something that I didn’t know. I’m a big fan of Eshell and usually reach for it first when I need a shell. One long standing problem I’ve had with it is clearing the screen. Doing a clear, as you would in other shells, doesn’t work. You can do a clear in Eshell but it doesn’t do what your expecting.
To deal with this, I long ago wrote a bit of code that lets me use the universal argument to clear the screen when I finish with an Eshell session. I like to run Eshell in full screen, which I invoke with Hyper+e, so the following lets me start and stop an Eshell session optionally clearing the history (by quitting Eshell) when I exit.
(global-set-key (kbd "H-e") (lambda (exit) "Bring up a full-screen eshell or restore previous config. With a prefix argument, exit eshell before restoring previous config." (interactive "P") (if (string= "eshell-mode" major-mode) (progn (when exit (insert "exit") (eshell-send-input)) (jump-to-register :eshell-fullscreen)) (progn (window-configuration-to-register :eshell-fullscreen) (eshell) (delete-other-windows)))))
The result of that is that Eshell forgets its previous content when I exit it with the universal argument.
Borkowski’s tip is really simple. If you want to clear the Eshell buffer, you can do it by specifying clear with an argument. Thus, clear t will clear the Eshell buffer in the way you’re expecting. That’s very nice and good to know.