Polymode
Closed this issue · 16 comments
Hi,
I have started implementing a polymode (https://polymode.github.io) for your gams-mode to handle the Python code embedded in GAMS ($onembedded Python:).
For now, this just lives in my init.el. Are you interested in a PR?
Best,
Christophe
Hi,
I'm not sure if the polymode works consistently with gams mode, but I'd like to see your code anyway, so can you send me a pull request?
Hi
When defining a new polymode, it is often necessary to create a separate lisp program. Following the same method, I created a program called poly-gams.el to use polymode in GAMS.
https://www.dropbox.com/s/t7mtzijkb9rx8g2/poly-gams.el?dl=0
Could you please try to use this program? Put this in the folder included in the load-path and add the following code to init.el
(require 'poly-gams)
When you open gms files, you should be able to use polymode in GAMS mode automatically.
Please let me know if you find some problems and let me know if you have any requests.
Hi Christophe,
I want to check what the problem is. Could you upload (or send me by email) a file where the coloring feature doesn't work well?
Hi @ShiroTakeda,
Your poly-gams.el works really well for me. Do you plan to integrate it to the package?
poly-gams.el" depends on the package "polymode".
In such a case, it seems preferable to provide "poly-gams.el" as an independent package instead of including it in GAMS mode. For the same reason, my "gams-ac.el" is in a separate package. If there are no problems, I would like to provide "poly-gams.el" as a separate package. In that case, I would like to create a repository for the "poly-gams" package on Github.
Any opinions on this?
Hi,
I am back from vacation, so I can give you my thoughts.
Personally, I do not mind using packages with dependencies. Now, with the Emacs packaging system, this is totally transparent for most users (except those stuck behind a corporate firewall who have to install packages manually). However, I perfectly understand your concern, and putting this piece in a separate package would work just as well.
Another point going in your direction is that while polymode is super useful, it does not seem to be really maintained, with barely any commits in the last 2 years despite numerous issues and PR. So, this may not be the kind of dependencies that one wants to have.
If you want to load poly-gams.el, you only need to install poly-mode yourself. Therefore, I do not think it is necessary to make poly-gams.el a separate package. Also, I think it would be easier to include it in GAMS mode, since it would be a little more work to install if it were a separate package.
However, the administrator of melpa, which I use to distribute gams-mode, has told me that programs that depend on other packages should be in a separate package. Therefore, I have decided to make gams-ac.el, which depends on auto-complete.el, a separate package as well.
For now, I would like to follow the advice of melpa's administrator and manage poly-gams.el as a separate package.
I have never distributed any emacs package, so I don't know anything about this, but I know that I get my packages from MELPA and they do come with dependencies (I just looked at my installed packages and I have a lot of them that have been automatically installed as dependencies). Here is an example: https://melpa.org/#/poetry that depends on https://melpa.org/#/pyvenv. This is the same for gams-ac which depends on auto-complete.
However, I understand the logic for gams-ac.el: it depends on auto-complete and not all gams-mode users will want to use this completion framework. However, poly-gams.el is different. The people from GAMS have announced that they will deprecate traditional data input methods to privilege the GAMS connect approach. Since GAMS connect is based on yaml, the embedded code feature will have to be used by all serious GAMS users. They will not all use python, but they will have to use yaml. So, this would be great to have it as a core feature.
But if it requires installing a separate package, it is no big deal either. Both solutions work, so do as you prefer.
I had not yet used the GAMS connect feature and did not understand the importance of the poly-mode support, but your message helped me understand its importance.
However, I will manage poly-gams as a separate package for now. If the integration does not seem to be a problem, I will eventually integrate it into GAMS mode.
Great! Let me know if I can help.
For me, the great point of GAMS connect is that it is multi-platform, contrary to tools such as gdxxrw which works only on Windows.
Since you do not use this feature, it is good if a few users take some time to test edge cases of poly-gams before integrating it into the core base.
I have created a new repository on GitHub for poly-gams.el.
https://github.com/ShiroTakeda/poly-gams
If you don't mind, I would like to authorize you to commit to the gams-mode and poly-gams repositories. You will be able to commit directly without a pull request.
Thanks a lot for your trust.
I registered poly-gams package to melpa. Now you can install it from melpa.