Even in the age of smartphones I still prefer to check the calendar on my computer and I’ve often been disappointed by the horrible default calendars that ship with some operating systems (e.g. macOS’s calendar accessible via its systray).
Fortunately for us, Emacs users, we always have access to a proper calendar regardless of our OS and desktop environment (if any) -
M-x calendar. By default it looks something like this:
A post-modern text editor.
While discussing with fellow developers, I was asked the following question a few times: We spend most of our time as developers thinking, not editing code; so, why invest time into mastering a complicated code editor, and why lose some cognitive resources on thinking about text editing instead of about the real programming problem?
I think this point of view is misguided, for a few reasons:
Despite their name, code editors are not only about editing, but also about code navigation. Programming is a hard task partly due to the huge amount of context we have to keep in mind, and being able to quickly navigate code helps us refresh that context, by looking at definitions, implementations, and comments.
Although code editing itself is not the most important part of programming, it still takes non-negligible time to perform, and can be optimized by using better tools.
Finally, a programming career spans a few decades, so investing a few weeks to improving our editing and navigating speed is definitely worth it.
I have heard about Neovim for a long time. I can say that I really appreciate and adopt the ideas of Neovim – it’s more progressive, embraces open source community, and tries to make Neovim approachable to more developers.
However, for its functionality, I didn’t see much difference between Vim. There are various reasons. Firstly, Neovim is a drop-in Vim, so even the plugins could compat each other without much modification, if it is not implemented with Vim or Neovim specific feature. And Neovim somehow pushes Vim to evolve and release similar improvement. e.g., asynchronous job. For an end-user without much deeper knowledge, the biggest differences might be
XDG_PATHbased directory and
People often wonder why SQLite does not use the Git version control system like everybody else. This article attempts to answer that question. Also, in section 3, this article provides hints to Git users about how they can easily access the SQLite source code.
This article is not a comparison between Fossil and Git. See https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wiki for one comparison of the two systems. Other third-party comparisons are available as well - use a search engine to find them.
This article is not advocating that you switch your projects away from Git. You can use whatever version control system you want. If you are perfectly happy with Git, then by all means keep using Git. But, if Git is not working well for you or you are wondering if it can be improved or if there is something better, then maybe try to understand the perspectives presented below. Use the insights thus obtained to find or write a different and better version control system, or to just make improvements to Git itself.
The first stable release of Sublime Text 4 has finally arrived! We’ve worked hard on providing improvements without losing focus on what makes Sublime Text great. There are some new major features that we hope will significantly improve your workflow and a countless number of minor improvements across the board.
str(…)macro to handle them all.
int table = 13; int id = 37; str test1 = str(“SELECT * FROM “, table, ” where person_id “, id); str test2 = str(test1); //copies test1 to test2 str test3 = str(test2, test1); // returns concat of test2 and test1
test2 = test1; // acceptable, but wrong since test2 now points to test1 not copies it.
str(test1); // returns const char to use in printf like functions Ex: puts(str(*test1)); // prints test1;
Once, there was a civilization (the Lisp Machine world) a lot like ours, but more advanced, with greater powers (like symbolic computation, automated learning, and LISP).
Then, in one tragic moment (er, decade - the 1980’s), it was destroyed.
But because of the wisdom of Jor-El (Stall-Man), because he realized that the human race had the capacity for good, he sent us his only son (editor).
His name is Kal-El (elisp). He will call himself Clark Kent (Editor MACroS), but the world will know him as… Superman (Emacs).
I’ve had a good couple of years in terms of tool discovery. Rather than try to tweet about them in bits and bobs, I figured I would write up a few bits and pieces that I like.
In recent years many new build systems have emerged to replace traditional make. Although they all have different strengths and weaknesses, one common theme is improving execution performance of the build system.
Traditional multiprocessor make systems are generally efficient at scheduling tasks within a given Makefile. Given a dependency graph, child processes can be executed when their dependencies are satisfied and processor cores are available.
Unfortunately, this breaks down where multiple Makefiles are used across different directories or modules. The choice that a build system maintainer faces becomes:
Using per-directory Makefiles allows developers to compile individual directories in isolation, but doing so means a full build needs to drain out child processes at various points in the build, because the engine cannot recognize dependencies natively;
Using fewer Makefiles means more efficient full builds but more difficult isolated compilation, as the developer would need to change directories and specify the correct target to build.
However, there’s no reason that this choice is inevitable. If the full build can construct a single global dependency graph, but each directory still contains a partial dependency graph, a directory build can operate as well as traditional make and a full build can operate as efficiently as a newer build system. YMAKE attempted to build such a system, and do so without requiring any changes to per-directory Makefiles.
Specifying the global graph requires a new syntax to logically graft a child directory into the dependency graph. The remainder of Makefile syntax does not need to change, and conditionals can be used to fall back to recursive navigation if a global dependency graph is not supported. This means that the build system does not require developers to install new build tools to compile, so it still benefits from the ubiquity of make, but having YMAKE just makes the existing build system faster.
While Emacs proponents largely agree that it is the world’s greatest text editor, it is almost as much a Lisp machine disguised as an editor. Indeed, one of its chief appeals is that it is programmable via its own programming language. Emacs Lisp is a Lisp in the classic tradition. In this article, we present the history of this language over its more than 30 years of evolution. Its core has remained remarkably stable since its inception in 1985, in large part to preserve compatibility with the many third-party packages providing a multitude of extensions. Still, Emacs Lisp has evolved and continues to do so.
Important aspects of Emacs Lisp have been shaped by concrete requirements of the editor it supports as well as implementation constraints. These requirements led to the choice of a Lisp dialect as Emacs’s language in the first place, specifically its simplicity and dynamic nature: Loading additional Emacs packages or changing the ones in place occurs frequently, and having to restart the editor in order to re-compile or re-link the code would be unacceptable. Fulfilling this requirement in a more static language would have been difficult at best.
One of Lisp’s chief characteristics is its malleability through its uniform syntax and the use of macros. This has allowed the language to evolve much more rapidly and substantively than the evolution of its core would suggest, by letting Emacs packages provide new surface syntax alongside new functions. In particular, Emacs Lisp can be customized to look much like Common Lisp, and additional packages provide multiple-dispatch object systems, legible regular expressions, programmable pattern-matching constructs, generalized variables, and more. Still, the core has also evolved, albeit slowly. Most notably, it acquired support for lexical scoping.
The timeline of Emacs Lisp development is closely tied to the projects and people who have shaped it over the years: We document Emacs Lisp history through its predecessors, Mocklisp and MacLisp, its early development up to the “Emacs schism” and the fork of Lucid Emacs, the development of XEmacs, and the subsequent rennaissance of Emacs development.
Here’s a fun game for you: what do you expect to be the state of the filesystem after running the following commands in an empty directory on a Linux system?
$ touch foo:bar $ tar -cpf foo:bar.tar foo:bar $ rm foo:bar $ tar -xpf foo:bar.tar
Do you expect the directory to contain the files
Like programming in C or driving a car, contemporary shellscript languages require some knowledge and discipline to use safely, but that’s not to say it can’t be done.
In the optic to enhance our embedded system’s security, having a compiler plugin feature is fundamental to add new features at compilation time without having to modify the compiler itself (and with minimum knowledge of compiler internals!) This article addresses GCC versions 9 and above on Ubuntu 20.04 LTS. I hope the guide can be enjoyed for other OS/GCC Version.