Xah Emacs Blog Archive 2016-11
Elisp: Lisp Symbol. understand lisp symbols. (complete rewrite)
the emacs manual mirrored on my site, is also updated to version 25.1. see (info "(emacs) index")
though, i rarely link to it. Because, if you want to learn emacs, there are quite a lot approaches that's more efficient than reading emacs manual.
- Just use emacs. Use and use, profusely. When you have a issue, seek answer, on the web, on xah tutorial, or ask stackoverflow, reddit.
- When you have leisure time, start learning emacs lisp.
- To learn emacs lisp, my advice is just to read my elisp tutorial. Practical Emacs Lisp. There's not much material elsewhere.
- While you are learning elisp, write helpful commands you need. And in the process, you'll have questions, then, seek answer.
- You will start to read parts of elisp manual now and then. This is real progress, making you understand emacs.
- Soon, you'll want to write a non-trivial package. This is when, you start want to read the elisp manual thoroughly.
the how to write a emacs major mode series, all pages have been updated. see Emacs Lisp How to Write Major Mode
Emacs: Quote Lines (new command)
how often do you change your emacs init?
reddit: evil mode vs emacs keys
i've researched this issue a lot.
- Emacs vs vi: How to Compute Keybinding's Efficiency?
- on vi Keybinding vs Emacs Keybinding
- vi, Emacs, Keybinding Design
about your specific list, like /r/angelic_sedition, i think some items can be made more precise, while some items may not be relevant without a precise goal. For example, your 3rd item about “harder to create specific keybinding…”. Is your goal/question about emacs, or about generic context with a programable keyboard such as ergodox? They have different answers. For example, if it's about in emacs, best is to avoid defining a key in keyboard firmware to send a chord that emacs uses. Better is just to directly define a keybinding in emacs. (unless there's some other issue, doing this as a workaround)
given a very flexible programable keyboard such as ergodox, and you want to program the keys, there's the choice of optimizing it for emacs, or optimizing for general use outside of emacs too. Or, somewhere in the middle ground. It depends on how much your time is spend in emacs. (for me, i optimize for emacs some 90%, because I almost type everything in emacs than paste it somewhere.) (if you optimize for emacs, there's of course also the question what key system you use, e.g. evil, or emacs default, or other.)
For general question about programing keyboard firmware for utmost efficiency, Gergely Nagy wrote a great article. See
[Multi-purpose keys, and a case for small keyboards By Gergely Nagy. At https://asylum.madhouse-project.org/blog/2016/10/15/multi-purpose-keys/ , accessed on 2016-12-23 ]
in general, modal mode will save you key strokes, all thing considered (including the need to press a key to switch mode), i estimate that modal mode saves you about 10% count of key press.
also, note that vim modal mode is not efficiently designed. The key choices are mostly historical, not based on command frequency.
emacs default keys are also historical.
Lastly, i'd say, if you want the most efficient modal mode based on command frequency statistics and ergonomics, might try Emacs: Xah Fly Keys you want the same but based on chords, then ergoemacs-mode http://ergoemacs.github.io/. Evil mode is great in that it is fairly efficient, and have the advantage of also muscle memory of using vim, make it a good choice on wide range of computers one may need to type on without config.
new. on melpa by request. xah-reformat-code (20161216.1859) --- commands to reformat source code. https://melpa.org/#/xah-reformat-code
explanation at Emacs: Reformat Lines for Source Code
Emacs: Rename File from Space to Hyphen/Underscore (bug fix. Now will also rename the buffer if open.)
elisp manual updated
the gnu emacs lisp manual mirror on my site is updated to emacs version 25.1. See (info "(elisp) index")
the gnu emacs manual html version CSS has improved in recent years. In 2013, it's still 1999 era html. Now it's modern looking.
Emacs: Eww Web Browser (new screenshot)
why a file variable “lexical-binding: t” is better than a special function “lexical-let”?
emacs skeeto (chris wellons, author of elfeed, skewer, etc) explains advantages and workings of lexical binding really well.
The advantages of lexical-binding:
- It has a measurable performance advantage. For example, variable accesses are simple array loads (stack-ref opcodes) rather than global variable lookups (varref opcodes), and the compiler can optimize away lexical variables.
- It's less buggy, since local variables aren't exposed to callees.
- The compiler can perform additional checks and will provide additional warnings.
- It applies not just to let, but to all forms that create local bindings, such as function parameters, condition-case, and any macros that expand to let.
He then proceed to explain in terms of bytecode. Be sure to read it in the link above.
One of the reason, that lexical binding applies to not just
let but also function parameters, condition-case etc, convienced me why file level declaration is the right choice, with respect to language design.
“lexical-binding: t” vs “lexical-let”?
What's the reason of introducing file variable “lexical-binding: t” instead of a macro/special-function such as “lexical-let”?
nice to see math symbol used in emacs.
the symbol used is ⊣ (U+22A3: LEFT TACK)
See also: Unicode Math Symbols ∑ ∞ ∫ π ∈ ℝ²
emacs lisp lexical scope, and the problem of bandwagon
updated all my packages to use lexical scope.
Here's functions updated that has a tutorial page:
- Emacs: Delete Whitespace around Cursor
- Emacs: Cycle Space Hyphen Underscore
- Emacs: Insert Date Time
- Emacs: Select Line, between Quotes, Extend Selection
to declare lexical binding, add this to the first line of your elisp file:
;;; xyz.el --- xyz does xyz. -*- coding: utf-8; lexical-binding: t; -*-
if your elisp package uses lexical binding, you also need to declare this:
;; Package-Requires: ((emacs "24.1"))
That's the convention of emacs version requirement declaration used by melpa package repository.
lexical binding is introduced in emacs 24.1 (24.4. is released in 2014-10)
lexical binding makes elisp code run slightly faster, and elisp compiler will find more errors, such as unused local variable. And pave the way for the future of elisp. (e.g. concurrency)
one interesting finding is that this form of function call:
((lambda (x) (+ x 1)) 3)
is deprecated. You should do:
(funcall (lambda (x) (+ x 1)) 3)
- Scheme lisp
the problem with elisp is that a function doesn't just return a function.
Instead, elisp has symbols, and a symbol has function cell and value cell.
The value cell could potentially contain another symbol whose value is
another function (i.e. symbol with function cell). In other words, a function
isn't just a function, but could also be a variable, and the value of the
variable could also be a function. So when you have
(f arg), that f could be a function itself, or could be a variable that holds a function.
This is the same problem with Common Lisp.
In the case of
((lambda …) arg), it works, but i suppose is deprecated because in general won't work with arbitrary expression for the head.
another thing i never understood, is why emacs dev introduced a directive for lexical binding. I rather prefer a new function/macro, such as “lexical-let”.
by the way, if you write code properly, for example, always use function without side-effect, and always use local variable, then you don't really need lexical binding. It has no effect.
my stance was, am never going to add that lexical binding directive. It really should be part of the language. If it is “lexical-let”, then i'd be happy to use it. But the thing is, usually you can't fight a trend in large society. When something becomes popular, that everyone is doing it, even if it is a stupid one, you can't simply stand aloof and to keep yourself of some superior way, because, when everyone is doing it, it has an effect on many other things and future change. Your “incompatible” superior way gradually gets in the way as things evolve with the inferior system. Example of such as QWERTY keyboard layout, unix, programing conventions, writing convention. For elisp lexical binding, it is the way things are and elisp is moving forward. If your code does not use such directive, your code will not be able to reap whatever advantages coming to it, will be left behind, and most coder don't understand will simply think your code is stupid.
js2-mode error highlight problem
js2-mode got this annoying syntax error highlight problem.
it sticks with the old school style of requiring semicolon. But thousands packages on npm follows new school style of no semicolon.
if you want js2-mode features, a solution is the derivative js3-mode.
in emacs 25.1, the variable ido-separator is now obsolete. Replaced by a element in ido-decorations
for new elisp code to config, see updated:
emacs lisp completion problem
start emacs with -Q, open a new buffer, M-x emacs-lisp-mode, type defu, press C-M-i, do you get “defun” or “defun-”?
this is quite odd. I remember it was working.
but apparently, about half of people, they don't get proper completion. (nor me. I'm on emacs 25.1.1)
it's interesting because:
- How could this basic functionality not work properly? it's emacs lisp in emacs we are talking about.
- How could there be different results? I asked people to start emacs with -Q, not loading init. So, perhaps this is the difference between emacs 24.5 and 25.1.1
- if it's indeed 25.1.1 issue, it's interesting how could emacs screw this up?
if you did get the correct behavior, did you actually start emacs with -Q? What emacs version are you using? (post comment on twitter or Google Plus.)
apparently emacs dev changed it
apparently, the logic is that, people type parenthesis first, then the function name. So, completion is changed to expect a word to begin with parenthesis, else, it refuse to complete.
This is bad. The old way will complete regardless if the string start with parenthesis or not. Now, it forces people to adopt the habit of typing parenthesis first. Typing word first is better, because completion can complete the parenthesis.
emacs, real auto save, and auto save when you call M-x
there's a package called real-auto-save, on melpa. It does “real” save periodically.
i was temped to write my own, but my current solution is that in Emacs: Xah Fly Keys , a modal key mode, everytime i switch to command mode, it also does a save.
you could do the same. For example, everytimes you call M-x, it does a save then M-x. Just write a short elisp command wrapper like “save-buffer-then-execute-extended-command”. If you want and don't know how, ask, many or i can show you how.
reading emacs manual vs elisp manual?
if you want to read emacs manual and want to be efficient in learning, read the elisp manual instead.
because emacs really is just lisp interpreter with a user interface. ie the GUI or TUI in terminal
this emacs lisp interpreter environment, is beyond repl. You can eval any buffer, or code, anytime, as in a interactive notebook.
emacs has a repl on top of emacs lisp environment, M-x ielm
[see Evaluate Emacs Lisp Code]
elisp manual is hard to read. You have to go thru hundred pages just to cover elisp basics. GNU Emacs Lisp Reference Manual (info "(elisp) index")
the hundred pages of elisp manual is summarized just by 10 pages here Emacs Lisp Basics
Emacs: Xah Math Input Mode now can be buffer local or global. Emacs: Xah Math Input Mode
Emacs: Xah Emacs Lisp Mode Much update in past months. If you had problem with company mode, now it's fixed.
just tried Emacs: Xah Fly Keys on emacs 24.5.1 started with -Q. runs smoothly
the emacs dumper dispute
another controversy in emacs. https://www.reddit.com/r/emacs/comments/5frpp4/the_emacs_dumper_dispute/
updated code. Now
xah-goto-matching-bracket will jump to matching quote too. And fixed a bug in
gnu emacs disabled a feature for Mac OS X so that it isn't better than linux version of emacs
gnu emacs removed code for color emoji feature in Mac OS X. see
[Bye Bye Emojis: Emacs Hates MacOS By Sebastian Wiesner. At http://www.lunaryorn.com/posts/bye-bye-emojis-emacs-hates-macos.html , accessed on 2016-11-21 ]
On the OS X Cocoa (“Nextstep”) port, multicolor font (such as color emoji) display is disabled. … This will be enabled again once it is also implemented in Emacs on free operating systems.
see what the current leader jwiegley has to say, in comment above.
This decision wasn't something “I approved of”, in the sense you're thinking. I do use a Mac, and I do miss my color emojis.
GNU Emacs is a project of the Free Software Foundation, and when they deem an issue as relating to their political agenda, it trumps the technical purview of the project maintainer. I keep Emacs going from a software point of view; they keep the FSF going as a movement.
If RMS says that such a change relates to freedom, I can either acquiesce or walk away. I didn't think color emojis were important enough to walk away. The gcc/clang dispute was part of the reason the last maintainer walked away.
It's a free project. If a group of people is willing to put in the effort, you could fork Emacs and make it into something better, freed from the FSF's policies. Until that happens, expecting them to change by writing blog posts, or commenting on Reddit, is not going to have any effect whatsoever.
by the way, it has always been like that. Every few years, major things like this happen got into news.
See also: GNU Emacs and XEmacs Schism
Emacs: Move Cursor to Bracket/Quote. new command
after a decade of back and forth about using this command vs
copy-to-register, i think this is far better.
Emacs: Cycle Space Hyphen Underscore (more code update. Now works inside parenthesis or bracket if is.)
keyboard efficiency tip: never mouse aim to close tab
keyboard efficiency tip: never mouse aim to close tab. too much effort. Middle click tab also takes aim. Set Pause key to close tab. Or, F13.
also, set F11 F12 to switch prev/next tab. Make use of all your Function Keys F1 F2…
see how to here: Why Function Keys F1 F2 Are Useful
in emacs, do the same. close buffer, next/prev user buffer, all single, one, key.
when kill buffer, stop emacs from confirming. also, a key to reopen last closed. see how to here: Emacs: Open Last Closed File
command to switch to Next/Previous User Buffer. Skipping scratch, info, shell out, etc buffers. Emacs: Next/Previous User Buffer
if you have a numpad, best is to set keys / * - to prev buffer, next buffer, close buffer. here's how: Emacs: Bind Number Pad Keys
Emacs: Change Brackets/Quotes (rewrite code. Now better code, also highlight changed places.)
emacs abbrev setup: using emacs commands vs using elisp code
after trying to use emacs abbrev commands to build list of abbrevs for a year, don't like it. Am reverting back to using elisp code for abbrev in my emacs init.
The advantage of just following emacs abbrev commands to create edit save abbrev is that, you have a tally of how many times you used each abbre. Sounds useful, but after 3 months, i find that the info isn't useful at all. I find that just a handful of abbrev i use daily, but i still want the rest abbrevs. The idea that i'll modify my abbrev based on the statistics of usage, didn't work out.
But mostly, the problem with following emacs abbrev command to create edit save abbrev is that, you have less control.
with abbrev as elisp code in my init file, i can control the regex used, the expansion function, the hook after expansion, for each abbrev. And, i can just edit it as easily.