GithubHelp home page GithubHelp logo

Comments (6)

dykstrom avatar dykstrom commented on June 14, 2024

This seems like an ambitious change. Can we do this in a branch so the changes will not be automatically deployed to MELPA each time I merge something? I'm not sure how github works. If I have a branch and you have a branch, can you make pull requests to my branch instead of master?

from basic-mode.

 avatar commented on June 14, 2024

Yes! I think so. I'm still researching this. There won't be code to commit at this point as the output from this issue will only be some researched suggestions for your consideration.

Based on what I've read so far I think the best way to move forward with this will be to simplify basic-mode as much as possible, then specialize it with define-derived-mode for each dialect for which support exists. There would be a generic basic-mode, and then N derived modes, 1 for each dialect. (i.e. basic-qb45-mode, basic-basica-mode, basic-gw-mode, basic-qb71-mode, basic-pet-mode). Doing it this way makes it easy to split the dialect specific stuff off into separate source files and it also keeps the complexity out basic-mode since the behavior will be overridden in each dialect derived mode instead of configured with customizations in basic. It'll ensure that you never need to:

;; yuck! Let's avoid this.
(cond ((string= major-mode "basic-45-mode") x)
          ((string= major-mode "basic-mode") y))
...

For instance, there may be a basic-qb45-mode that is derived from basic-mode and extends the syntax table, adds additional indentation, etc...

As for telling emacs which mode to use automatically, I've settled on the below strategy.

  1. If a user frequently works with multiple dialects, the user will set the mode using the file variable. The benefit of this is that is already implemented by Emacs. No additional work is required to support it.
REM -*- mode: basic-MYDIALECT-mode -*-
  1. If the user works primarily with a specific dialect, then the user can use the standard auto-mode-alist configuration.
;; I mostly work with QB45 so that is the default mode I use
(add-to-list 'auto-mode-alist '("\\.bas\\'" . basic-qb45-mode))
  1. Finally, the default setting is to just use the more general basic-mode if nothing else is specified.

Please let me know what you think, and thank you for your consideration!

from basic-mode.

dykstrom avatar dykstrom commented on June 14, 2024

Hi, sorry for taking so long to respond! To be honest, I am not sure I am qualified to decide what is the best way to go forward. I do not consider myself an Emacs Lisp expert, even though I happen to have written a major mode. However, since I am now the maintainer of this mode, I will have to decide on something.

I would like basic-mode to work in such a way that an occasional user, that just wants to try it out, edit some BASIC code, and feel nostalgic, should be able to do this very easily. Ideally, he should not have to customize anything, but get reasonable functionality out of the box. At the same time, regular users should be able to customize, or otherwise make their Emacs adapt to the BASIC dialect of their choice.

I think your suggested solution at least satisfies the second requirement. As for the first requirement, I think it depends on how much we put into the general basic-mode, and which defaults we use.

Some questions:

  1. With this solution, will there be several files, for example basic-mode.el, basic-qb45-mode.el, etc?
  2. The default autoload provided by the package system would be for the general basic-mode I guess. So if the user wants a specific dialect, he would have to add another autoload for his preferred dialect in his .emacs file?
  3. Have you thought about what to do with functionality that is common to several dialects, but not relevant for other? As an example we can take line numbers. There is a lot of code to handle line numbers. This code would be used by the BASICA dialect, the Sinclair dialect, and also the QB45 dialect. But it would be irrelevant to the VB dialect. Would we then put line number code in the general basic-mode so that it is inherited by all dialects, and somehow ignored by basic-vb-mode, or would it be defined in several dialects, or maybe included from a separate file?

from basic-mode.

 avatar commented on June 14, 2024

With this solution, will there be several files, for example basic-mode.el, basic-qb45-mode.el, etc?

Yes. This is to help reduce the complexity of extending basic-mode for each dialect. It also provides a more direct approach for contributors to implement their personal favorite dialect of basic. Wikipedia shows that there are many dozens of dialects out there.

https://en.wikipedia.org/wiki/List_of_BASIC_dialects

The default autoload provided by the package system would be for the general basic-mode I guess. So if the user wants a specific dialect, he would have to add another autoload for his preferred dialect in his .emacs file?

Correct. The user has to override the autoload to use their preferred dialect. This is a one liner in their Emacs init script (init.el, .emacs, etc...).

Have you thought about what to do with functionality that is common to several dialects, but not relevant for other? As an example we can take line numbers. There is a lot of code to handle line numbers. This code would be used by the BASICA dialect, the Sinclair dialect, and also the QB45 dialect. But it would be irrelevant to the VB dialect. Would we then put line number code in the general basic-mode so that it is inherited by all dialects, and somehow ignored by basic-vb-mode, or would it be defined in several dialects, or maybe included from a separate file?

This is definitely an engineering problem. Tentatively, I would suggest a tree of derived modes. For example:

  • basic-mode
    • basic-a-mode
    • basic-gw-mode
    • basic-qb-mode
      • basic-qb11-mode
      • basic-qb45-mode
      • basic-qb71-mode
    • basic-vb-mode
      • basic-vb6-mode
      • basic-vbdotnet-mode

To be clear, the goal is not to immediately create all of these! But instead to provide a simple pattern that allows these modes to grow organically over time. I plan on contributing the qbasic mode set myself as I was already working on a similar effort.

Finally, this looks good on paper, but you won't know for sure how well this will work until it is attempted. If you'd like, I can attempt a refactoring to produce the set of modes basic-mode -> basic-qb-mode -> basic-qb11-mode in order to test the concept.

Thank you for taking the time to review my ideas. :)

from basic-mode.

dykstrom avatar dykstrom commented on June 14, 2024

OK, so this sounds like a solution that might work. I'm a little afraid that it will be complicated with the inheritance and all. After all, it is not Java or C++ we are talking about here, but Emacs Lisp. But maybe it will work out fine. Please go ahead and make a POC for the inheritance concept, so we can test and discuss an actual implementation. It will be interesting to see how it turns out.

from basic-mode.

hackerb9 avatar hackerb9 commented on June 14, 2024

Please see #20 for a proof of concept. It is based on the TRS-80 Model III Basic Reference card.

@ghost: You seem to have a much better understanding of the different variations of BASIC than I do. Do you think you could create a listing of the functions, builtins, and keywords for each of the major dialects you listed? For the hierarchical ones you could just show the difference from the parent (e.g., +screen, -usr)

Also, it would be good to know if they have syntactical differences, such as apparently QuickBasic allowing . in an identifier, so it can't be treated as punctuation.

from basic-mode.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.