Include electric-spacing for R coding style
Hi William,
As I told you, I was working to extend electric-spacing for the R coding style based on what you did for C++. I did this in a new file, ess-electric-spacings. I did some testing, it seems to be working well. Now I can submit a pull request but I was thinking if is better to put electric-spacing-* characters definitions in separated files, one for each mode/language, and keep generic functions (those in the top of file) in the electric-spacing.el. This way, electric-spacings-c++.el and electric-spacings-r.el would be created now. The main file would call one of the other files based on the current major mode. Moreover, in the future someone can easily add more extensions, like python and shell.
Bests.
That's actually a good idea. Each electric-spacing-MODE.el will only customize interested operators. Like you said, it will be easier to extend for other modes. I'm not sure when i could do this. Patches are welcome, :)
I will create the electric-spacings-{c++,r}.el and keep non mode dependent functions in the electric-spacing.el. What I don't know yet is how will we set in the .emacs to call for each major mode the corresponding electric-spacing-*.el file. Do you know how to do this?
@xwl, I've created files to the specific mode electric-spacing functions, *-c++.el and *-r.el. In the main file, electric-spacing.el, I kept only main function (non mode specific). I'm using this in my .emacs:
(require 'electric-spacing)
(require 'electric-spacing-r)
(add-hook 'ess-mode-hook #'electric-spacing-mode)
However, I'm sure that this is not the best way. How avoid (require 'electric-spacing-r) but ensure that the electric-spacing functions for R were loaded (the same for other modes)?
i have something like this in mind:
- electric-spacing.el defines: (defvar electric-spacing-customized-modes '(c++-mode r-mode))
- Then, e.g., when inserting %,
- check if current mode is in electric-spacing-customized-modes,
- if yes, load the file (require 'electric-spacing-c++);
- check if mode has defined its own version of % (using boundp);
- if yes, call it
- check if mode has defined its own version of % (using boundp);
- else call default implementation.
So the user only needs to know and use electric-spacing.el.
I agree with you completely. This must ensure that the user can edit a c++ buffer and a R buffer in the same Emacs and electric-spacing change accordingly to the current mode, right?
What about let the user define what symbols he want to be electric in a major mode? Lets suppose a R user doesn't want electric-spacing for math symbols (+-*) or want "electrify" a new symbol (\ for example), how he can disable/enable them in the .emacs without touch the electric-spacing source code? Is it possible?
2016年1月27日星期三,Walmes Zeviani [email protected] 写道:
I agree with you completely. This must ensure that the user can edit a c++ buffer and a R buffer in the same Emacs and electric-spacing change accordingly to the current mode, right?
Correct.
What about let the user define what symbols he want to be electric in a major mode? Lets suppose a R user doesn't want electric-spacing for math symbols (+-*) or want "electrify" a new symbol (\ for example), how he can disable/enable them in the .emacs without touch the electric-spacing source code? Is it possible?
Each mode can define a reasonable good default setup.
For the user to have finer control, he can either:
- With C-q prefix, to insert it without electrify
- Bind the symbol to other functions in mode hooks
I have not thought about adding new symbols. You also need to think about where to insert spaces, whether to combine with other symbols. It may not be that straightforward to provide such an customization option. So, in the end, the user may just defines new functions using some electric-spacing functions. (No need to change electric-spacing, of course )
-William
Has there been any further progress with this issue? I would be keen to see support for R as well. Thanks for your time.
@doolio, I'm using the electric-spacing since the day I opened this issue. Some times I do an improvement or a bug fix for using the R language code style. I need to merge the branches created to have a stable version of the electric-spacing of R. I'm happy you have interests in it. I will prepare the things as soon as possible. The current definitions I'm using are in the https://github.com/walmes/electric-spacing/blob/restart/ess-electric-spacing.el file. To call, see https://github.com/walmes/emacs/blob/helm/dotemacs.el#L492.
Excellent, whenever you can. And is the intention then to merge your work here or to maintain your fork?
Hello guys.
After using the electric-spacing a lot and my students having used it too, I think I finally have a useful version of it. There is only one feature that I couldn't develop (regarding to the %op% operator). Maybe you can help with that in the future.
Which is the best way to make this contributions available: 1) to keep it with the electric-spacing or 2) to create a separate package for R users?
Should I do a pull request now?
Visit: https://github.com/walmes/electric-spacing
Hi, i have created a new branch 'dev', allowing major mode specific tunings. I would be happy to merge a electric-spacing-r-mode.el.