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

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.

why a file variable “lexical-binding: t” is better than a special function “lexical-let”?

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.

Closures.

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.

2016-12-19

“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”?

but actually, the funcall form is inferior. It introduces a new function. Most other langs don't need it. For example, scheme lisp, clojure, JavaScript, Wolfram Language and most other modern languages can directly call function in the form of normal function call, simply replace the function name by a function expression.

For example,

Scheme lisp (function_expressionargs)

JavaScript ((function_expression)(args))

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 (farg), 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.

2016-12-15

js2-mode error highlight problem

emacs js2 mode syntax error highlight problem 2016-12-15

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.

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.)

answer

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.

2016-12-09

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.

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.

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.