Irreal

In my post on Omar Antolín Camarena’s May Emacs Carnival contribution explaining his reasons for using EWW as his default browser, I mentioned that Camarena said that one of the benefits of EWW not supporting JavaScript is that JavaScript is mostly used to make the user’s experience worse by doing things like loading ads, reconfiguring the user’s display parameters, and implementing paywalls.

If you had asked me, I would have said that any site using a paywall would also require JavaScript to load the content and, indeed, that’s true for some sites such as The New York Times but, as I discovered, it’s not true for a surprising number of sites.

After reading Camarena’s post, I decided to experiment a bit to see if it was possible to bypass paywalls simply by not running JavaScript. I mostly don’t care about paywalls because the majority of the sites that use them don’t have content that’s worth the effort of avoiding them. Still, I thought it would be interesting to test if the strategy was feasible.

I did this by opening any site that popped up a paywall in EWW. It worked for a surprising number of sites. Again, it’s almost never worth the effort but if you happen upon an article that you really want to read on a site that wants you to sign up for an outrageously expensive subscription, it may be worthwhile seeing if you can open it in EWW,

The other thing I learned is that reading content with EWW can be a very restful experience. No ads, no blinkenlights, and sometimes, no paywall either. I didn’t try running EWW with eww-readable but that would probably make the experience even more restful.

Marcin Borkowski (mbork) really likes all the ways you can mark files in Dired but noticed that an easy way to mark recently modified files was missing. He knows quite a bit about writing Elisp so it was an easy decision to decide to write some code to implement the missing feature.

The code, which you can see at his post, is pretty simple and easy to follow. What wasn’t so easy were some annoying design decisions. For example, what constitutes the current day? Is it 24 hours ago until now or is it the previous midnight until now? And by the way, should that be UTC or local time?

The natural interface is to specify the number of previous days you want to mark as a prefix argument but that leaves open the question of how to unmark the last n days. The natural solution—and the one mbork chose—is to use a negative n to mean “unmark the last n days”. So positive n, mark files modified in the last n days; negative n unmark file modified in the last n days. What about 0? Mbork made the arbitrary decision to have that mean mark files modified in the last 60 minutes.

There are a couple of other nuances that you can read about in mbork’s post. The real takeaway for me is how tricky it can be to get the small details right. That seems especially true when you’re dealing with time calculations. Questions like, “What, exactly, does ‘yesterday’ mean” turn out to be a lot harder to answer than they first seem. Take a look at mbork’s post to see what I mean.

I see a lot of blog posts recommending EWW. Sometimes I even write about them. The common theme is something along the lines of, “No, you can’t really replace a full-fledged browser with EWW but you can do a lot and a ”real“ browser is only a keystroke away.”

In another May Emacs Carnival entry, Omar Antolín Camarena offers his reasons for using EWW. He agrees with the conventional wisdom that EWW isn’t a replacement for a normal browser but that it is useful in many situations and even has some advantages over your default buffer.

He believes that one of the chief advantages of EWW is that it doesn’t run JavaScript. That’s ironic, of course, because EWW’s lack of support for JavaScript is one of its most oft cited shortcomings. But Camarena says that lack is often an advantage because JavaScript is often used to load ads or a paywall or to reconfigure your display preferences often choosing low contrast colors that are hard for anyone but the young to read.

His second reason for using EWW is that it brings the power of Emacs to your Web browsing. Among the advantages he lists are:

• You can easily resize images without changing font and other sizes.
• You can read the Web site content in multiple columns using follow-mode.
• You can use occur for a search and keep a list of results and easily navigate among them.
• You can evaluate ELISP directly in the EWW buffer and many other language as well with a bit of plumbing.
• You can use eww-readable to eliminate a lot of the junk that comes with many Web pages.

And, as Camarena stresses, you can always escape to a normal buffer with eww-browse-with-external-browser, bound to & by default.

Charlie Holland has an interesting contribution to May’s Emacs Carnival, which this month is on the topic “If I may recommend…” His notion is that Emacs is an effortless bloom. The “effortless” part is because Emacs—contra conventional wisdom—is easy to use and can, in fact, significantly simplify your work flow by providing a uniform interface to several different computer programming languages and their environments. If you’ve ever had to negotiate such a collection, you know that this is not a trivial thing.

The “bloom” part is more nuanced. The idea is that like a rose whose roots “fan in” water and nutrients and whose flower “fans out” its petals and beauty to encourage pollination, Emacs has its own fanning in and out. The center of this action is the text buffer. Data from various sources can be fanned into a buffer from which it can be fanned out to various functions for processing. The altered text buffer can then be fanned out to other targets.

Holland’s post is a bit lyrical so you need to read it to get the full impact of his fan in, fan out metaphor. He considers whether any other editor could achieve the same power as Emacs. He concludes that any editor could, in theory, achieve the same power but in order to do so it would have to replicate the idea of the buffer as the single important data structure on which everything else operates.

It’s an interesting post worth a few minutes of your time.

Thanos Apollo has an interesting post about an almost forgotten Emacs battle: the choice between Bazaar and Git as the new version control system for Emacs. Twenty years ago, Emacs was still using CVS, a venerable RCS that was well past its sell date.. It was clear to everyone that a new system was needed. The question was which one. The two contenders were Bazaar and Git.

On the technical merits the choice was clear. Git was faster and more reliable and most, if not all, of the developers wanted to move to it. But there were political considerations. Bazaar was a GNU project and Git was not. RMS felt strongly that the GNU project should support its own applications and insisted that Bazaar be used and given a chance to improve. It was maintained by Canonical but they eventually abandoned the effort. Even though the development was stalled and error reports were piling up unresolved for years, RMS insisted on staying the course.

The saga would probably still be going on were it not for Eric Raymond (ESR). He had been working for some time on a utility to import various RCS systems into Git while maintaining whatever metadata the old system offered. At one point he decided to convert Emacs to Git. It was a particularly difficult problem because there was more than one source RCS in play and because some of the records were old and incomplete.

Nonetheless, ESR managed the conversion and in 2014 announced that he had the conversion scripts ready and was set to go. In November 2014 he ran his scripts and suddenly Emacs was available as a Git repo. The developers started using it and the battle was over.

Charles Choi is back with more menus. Most of you know that I generally eschew the use of Emacs menus but they definitely have a place in seldom used commands whose name or key shortcut are hard to remember. In most cases, it’s possible to play around with fuzzy command completion and find what you’re looking for but it’s a lot easier to simply use a menu if it’s there.

That’s where Choi’s latest update to Anju comes in. He says that the introduction of context-menu-mode in Emacs 28 made it possible to provide cotentxt sensitive menus for Elisp development and he has added it to the latest version of Anju.

His post has a couple of screen shots of his menus in action. In the first, the point is on a function definition and the menu, among other things, offers the choice to instrument that function. In the second, the function has been instrumented and now the (context sensitive) menu offers things you can do—such as step into, set a breakpoint, and others—with the function. Naturally all of this is dependent on where the point is. That’s the point: the menu is context sensitive.

Choi says that the use of the context menus has markedly improved his Elisp development. If you do some but not a lot of Emacs development, it may be a win for you. On the other hand, Choi certainly does do a lot of Emacs development and still finds it a win. Perhaps—no matter your normal workflow—you will too.