RFC: tab-substitution of LaTeX symbols in Emacs julia-mode

[stevengj]

Similar to the new REPL and IJulia behavior implemented in #6911, this allows you to type e.g. \alpha<TAB> in Emacs and get α. The list of substitutions is the same. When a Unicode substitution is not performed, the tab character indents as usual, so the change should be fairly unobtrusive.

[StefanKarpinski]

@stevengj – you are amazingly thorough.

[stevengj]

I just found that I was so spoiled by the new REPL behavior that I couldn't bear to live without it in Emacs.

[stevengj]

(The poor souls who don't use Emacs are on their own, though.)

[StefanKarpinski]

As I mentioned, there's a Sublime Text package for this. I guess someone will have to hack this into vi.

[BobPortmann]

Why not use the abbrev minor mode, since it is built for this kind of thing? Then your example would become \alpha<SPACE> (by default, although it is easy to switch it to \alpha<TAB> if you like that better). Then a bunch of handy code abbrev's could be added as well. These allow for inserting more complicated code blocks and placing the cursor in a handy spot at the end. E.G. \for<SPACE> could expand into

for C
end

where C shows the placement of the cursor.

[stevengj]

Are you referring to this plugin for Sublime? That one goes a bit further and converts to Unicode when you hit the space bar.

[stevengj]

@BobPortmann, my thinking on abbrev mode is:

• abbrev-mode seems oriented towards user-defined abbreviations in ~/.abbrev_defs, not something that comes with a major mode.
• The abbrev abbreviations seem to use a single global list, but we probably only want symbol substitution in julia-mode (e.g. you wouldn't want it in latex-mode in the same Emacs session, even if you have other user-defined abbreviations you want to use for LaTeX). Contrariwise, if you've defined abbreviations that you use in other modes but not in julia-mode, it would be unexpected and unfortunate if julia-mode were to turn on abbrev-mode.
• Performing substitutions using the space bar seemed too aggressive, particularly since \ is a Julia operator and there are Julia functions like gamma and beta.
• I'm not sure how to bind the abbrev mode to tab in a way that still allows tab to work for indenting.

With my implementation, the symbol substitutions are a "Julian idiom" orthogonal to abbrev mode. If you want to define your own abbreviations for for etcetera, you can do so, and it won't interfere with \alpha<TAB>.

[BobPortmann]

@stevengj OK, I am fine with your way but a few comments:

• the idlwave.el major mode uses abbrev mode by default and its always worked well for me. I don't know if that is unusual or not.
• the abbrev abbreviations in idlwave.el are local to that mode, so they are not using the global list. See lisp/progmodes/idlwave.el and search for "Abbrev Section" if you want to see how it is done there (they maintain a idlwave-mode-abbrev-table).
• I don't see how typing \alpha<SPACE> is any more aggressive than \alpha<TAB>. The former will not expand unless alpha is defined as abbrev. Otherwise it will show as is.
• I'm not sure about rebinding to <TAB>. I just assumed that anything is possible in emacs. <SPACE> is super nice IMO since it just gets expanded during normal typing.

[JeffBezanson]

If there is a variable called alpha used as the second argument to \, it would be very difficult to type.

[stevengj]

The fact that space just gets expanded during normal typing is precisely why space-substitution is more aggressive and more intrusive than tab-substitution. As Jeff pointed out, you might want to type x = A\alpha and it would be frustrating to see it transformed to x = Aα.

I wasn't aware of the local-abbrev-table, though; and, as you say, just about anything is possible in Emacs. Still, the fact that we are binding it to <TAB> makes me not want to interfere with the user's abbrev-mode for this, and since my implementation is under 30 lines it's not as if we are duplicating a lot of code.

[BobPortmann]

Well on my 1st try to type something that should expand in idlwave mode I tried \n<SHIFT-SPACE> and it worked (i.e., it didn't expand and \n should expand to n_elements()) so it is not hard to work around.

[carlobaldassi]

I guess someone will have to hack this into vi.

JuliaEditorSupport/julia-vim#21 (β-testers welcome)

[stevengj]

Ultimately, this is a matter of taste, but my feeling is that for new users it would be too confusing to have substitutions performed by the spacebar. In any case, we should be consistent between the REPL, IJulia, and julia-mode, and IJulia at least cannot do spacebar-expansion without patches to IPython.

It would be easy to add a spacebar binding later, or as an option.

[stevengj]

Is this okay to merge?

[StefanKarpinski]

Since @JeffBezanson is the one who's ok you're probably waiting for and he probably won't be able to check anything out until Sunday, you may want to just merge it and then undo it later if there are objections. Fortunately editor modes are not a big concern for code compatibility issues ;-)

[Keno]

Ah, excellent plan. Make such a mess of the code base that @JeffBezanson will never dare to be offline for any extended period of time again.

[StefanKarpinski]

Exactly ;-)

But seriously, given that this patch introduces a single contiguous block of code, independent of everything else, I don't think that's a huge issue.