Re: New ELPA package ada-lite

[Stefan Monnier]

>> Sounds good, as long as the other ada-mode will be modified to (require
>> and) derive from (or extend) ada-lite.
>>
>> Currently, if both ada-mode and ada-lite packages are installed and
>> activated, their autoloads will fight for the top spot of
>> `auto-mode-alist`.
>
> Hmm. I was assuming only one would be activated. In my current testing,
> I have ada-mode disabled in package-load-list, so I have not run into
> this problem.
>
> I don't see how deriving ada-mode from ada-lite-mode helps here; there
> are still conflicting entries in auto-mode-alist.

It doesn't for the `auto-mode-alist` issue.

Maybe the full ada-mode should be turned into a minor mode for
`ada-lite-mode` (like eglot-mode)?

> Are there other modes in ELPA (or MELPA?) that support the same file
> extensions?

There's a bunch of similar cases:
- Built-in tex-mode va AUCTeX
- cperl-mode vs perl-mode
- js-mode vs js2-mode vs js3-mode vs jsx-mode vs ...
- python.el vs python-mode.el

This is generally considered as a problem, so the better choice is to
try and avoid it.

The worst in the list above is python.el and python-mode.el because
AFAIK they can't be loaded at the same time (because of name conflicts).

In the JavaScript world we try to avoid it by consolidating these into
a base js-mode plus a bunch of minor modes (e.g. `js2-minor-mode` and
`js-jsx-syntax`).

I think the second-best choice is to have a single auto-mode-alist entry
and rely on function redefinition to make `<foo>-mode` point to the
desired alternative (e.g. (defalias 'perl-mode 'cperl-mode)).

>> `inhibit-point-motion-hooks` is t (and obsolete) since Emacs-25.
> Ah.  I guess the byte-compiler doesn't report an obsolete warning here,
> because it's in a let?

Nah, it's much simpler:

      DEFVAR_LISP ("inhibit-point-motion-hooks", Vinhibit_point_motion_hooks,
               doc: /* If non-nil, don't run `point-left' and `point-entered' 
text properties.
    This also inhibits the use of the `intangible' text property.
    
    This variable is obsolete since Emacs-25.1.  Use `cursor-intangible-mode'
    or `cursor-sensor-mode' instead.  */);
      /* FIXME: We should make-obsolete-variable, but that signals too many
         warnings in code which does (let ((inhibit-point-motion-hooks t)) ...)
         Ideally, make-obsolete-variable should let us specify that only the nil
         value is obsolete, but that requires too many changes in bytecomp.el,
         so for now we'll keep it "obsolete via the docstring".  */
      Vinhibit_point_motion_hooks = Qt;

> Can that be improved?

Maybe it's time we mark it really as obsolete, indeed.

>> - The second char in "\"'" is unused (it's only used for open/close
>> parentheses-like thingies).
> I guess "strings" are defined to always have the same start and end
> delimiters.

Indeed.  For those strings that don't obey this rule we have the "string
fence" syntax.

>>>   (set (make-local-variable 'syntax-propertize-function) 
>>> #'ada-lite-syntax-propertize)
>>>   (syntax-ppss-flush-cache (point-min));; reparse with new function
>> Why/when have you found this explicit flush to be necessary?
> When changing modes in a buffer, or just resetting the mode after
> editing ada-lite-syntax-propertize.

Really?

> You seem to be implying that syntax-ppss-flush-cache is already done by
> the "set major mode" code?

Yes, that should be the case (because the cache's info is kept in local
vars which get zapped by the `kill-all-local-variables`).

>>> (defun ada-lite-find-project (_dir)
>>>   "If ada-lite-mode, return ada-lite project.
>>> For `project-find-functions'"
>>>   (and (eq major-mode 'ada-lite-mode)
>>
>> I recommend (derived-mode-p 'ada-lite-mode) instead?
>
> That would be wrong for ada-mode if it derives from ada-lite-mode;
> ada-mode assumes a different kind of project. 

Hmm...


        Stefan