New ELPA package ada-lite

New ELPA package ada-lite

[Stephen Leake]

[-- Attachment #1: Type: text/plain, Size: 538 bytes --]

I'd like to add a package ada-lite-mode to ELPA; code attached. The
intent is to be a mode for Ada files that's easier to install than the
current ELPA ada-mode.

This can be used as-is, in which case all you get is reserved word
highlighting. Or it can be used with eglot and an Ada language server,
which gives many more features (some of which ada-mode does not have).

Installing the AdaCore ada_language_server is easier than installing the
executables for ada-mode; it can be done via Alire (https://alire.ada.dev/).

-- 
-- Stephe

[-- Attachment #2: ada-lite-mode.el --]
[-- Type: application/emacs-lisp, Size: 11128 bytes --]

Re: New ELPA package ada-lite

[Stefan Monnier]

> I'd like to add a package ada-lite-mode to ELPA; code attached.  The
> intent is to be a mode for Ada files that's easier to install than the
> current ELPA ada-mode.

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`.

A few more comments about the code:

> ;; To use ada-lite-mode for Ada files, put the following in your
> ;; emacs startup:
     ^^^^^
     Emacs


> ;; (require 'ada-lite-mode)

That shouldn't be necessary if the package is installed "the normal way".

> (defun ada-lite-font-lock-keywords ()
>   "Ada mode value for `font-lock-keywords'."
>   (list
>    (list (concat "\\_<" (regexp-opt ada-lite-keywords t) "\\_>") '(0 font-lock-keyword-face))
>    ))

I'd have split this into two to fit into the usual 80 columns.

> (defun ada-lite-syntax-propertize (start end)
>   "For `syntax-propertize-function'.
> Assign `syntax-table' properties in region START .. END.
> In particular, character constants are set to have string syntax."
>   ;; (info "(elisp)Syntax Properties")
>   ;;
>   ;; called from `syntax-propertize', inside save-excursion with-silent-modifications
>   (let ((inhibit-read-only t)
> 	(inhibit-point-motion-hooks t))

`inhibit-point-motion-hooks` is t (and obsolete) since Emacs-25.
And `inhibit-read-only` should already be t since we're within
`with-silent-modifications`.

>     (goto-char start)
>     (save-match-data

Why?

>       (while (re-search-forward
> 	      (concat
> 	       "[^[:alnum:])]\\('\\)[^'\n]\\('\\)"; 1, 2: character literal, not attribute
> 	       "\\|[^[:alnum:])]\\('''\\)"; 3: character literal '''
> 	       )
> 	      end t)
> 	;; syntax-propertize-extend-region-functions is set to
> 	;; syntax-propertize-wholelines by default. We assume no
> 	;; coding standard will permit a character literal at the
> 	;; start of a line (not preceded by whitespace).
> 	(cond
> 	 ((match-beginning 1)
> 	  (put-text-property
> 	   (match-beginning 1) (match-end 1) 'syntax-table '(7 . ?'))
> 	  (put-text-property
> 	   (match-beginning 2) (match-end 2) 'syntax-table '(7 . ?')))
> 	 ((match-beginning 3)
> 	  (put-text-property
> 	   (match-beginning 3) (1+ (match-beginning 3)) 'syntax-table '(7 . ?'))
> 	  (put-text-property
> 	   (1- (match-end 3)) (match-end 3) 'syntax-table '(7 . ?')))
> 	 )))))

I think

    (syntax-propertize-rules
     ("[^[:alnum:])]\\('\\)[^'\n]\\('\\)"
      (1 "\"'")
      (2 "\"'")
     ("[^[:alnum:])]\\('\\)'\\('\\)"
      (1 "\"'")
      (2 "\"'"))

would do basically the same, but:

- Is there a specific reason why you preferred to code it by hand
  (speed maybe?)
- The second char in "\"'" is unused (it's only used for open/close
  parentheses-like thingies).

You could merge the two into:

    (syntax-propertize-rules
     ("[^[:alnum:])]\\('\\)\\(?:'\\|[^'\n]\\)\\('\\)"
      (1 "\"")
      (2 "\""))


> (define-derived-mode ada-lite-mode prog-mode "ada-lite"

There's an autoload cookie missing here.

>   (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?

>   (set (make-local-variable 'parse-sexp-ignore-comments) t)
>   (set (make-local-variable 'parse-sexp-lookup-properties) t)
>   (set 'case-fold-search t); Ada is case insensitive
>   (set 'completion-ignore-case t)
>   (set (make-local-variable 'comment-start) "--")
>   (set (make-local-variable 'comment-end) "")
>   (set (make-local-variable 'comment-start-skip) "---*[ \t]*")
>   (set (make-local-variable 'comment-multi-line) nil)

You can use `setq-local` on all of those.

> (defcustom ada-lite-server-exec nil
>   "Location of an Ada language server.
> If non-nil, should be an absolute path to an executable for the
> server; this allows specifying a development version. See
> `ada-lite-find-server' for default behaviour.")

A `defcustom` without :type is like a meringue without double cream,
(or like a churro without dulce de leche, depending on your religion).

> 		   (expand-file-name
> 		    (concat (file-name-directory gnat)
> 			    "../libexec/gnatstudio/als"))))))

Why not just

	   (expand-file-name "../libexec/gnatstudio/als"
	                     (file-name-directory gnat))))))

?

> (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?

> (if (featurep 'eglot)
>     (add-to-list 'eglot-server-programs (cons 'ada-lite-mode #'ada-lite-find-server))
>   (eval-after-load "eglot" '(add-to-list 'eglot-server-programs (cons 'ada-lite-mode #'ada-lite-find-server))))

AFAIK

   (with-eval-after-load 'eglot
     (add-to-list 'eglot-server-programs
                  (cons 'ada-lite-mode #'ada-lite-find-server)))

should do the same (including run the code right away if the feature
is already provided).


        Stefan

Re: New ELPA package ada-lite

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel <emacs-devel@gnu.org>
> Date: Mon, 15 Aug 2022 15:04:56 -0400
> 
> > I'd like to add a package ada-lite-mode to ELPA; code attached.  The
> > intent is to be a mode for Ada files that's easier to install than the
> > current ELPA ada-mode.
> 
> 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`.

Would it make sense to have the lite mode in core?

Re: New ELPA package ada-lite

[Stephen Leake]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: emacs-devel <emacs-devel@gnu.org>
>> Date: Mon, 15 Aug 2022 15:04:56 -0400
>> 
>> > I'd like to add a package ada-lite-mode to ELPA; code attached.  The
>> > intent is to be a mode for Ada files that's easier to install than the
>> > current ELPA ada-mode.
>> 
>> 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`.
>
> Would it make sense to have the lite mode in core?

I don't think so; that would mean any use of ada-mode would cause a
conflict in auto-mode-alist.

Hmm; if all core package autoloads are executed before all ELPA package
autoloads, that would at least be deterministic; if the ELPA package is
installed and active, it's entry is first in auto-mode-alist and thus
always wins.

If both are ELPA packages, the order probably depends on file-system
sorting, or sorting on the package name, or something equally obscure.

-- 
-- Stephe

Re: New ELPA package ada-lite

[Eli Zaretskii]

> From: Stephen Leake <stephen_leake@stephe-leake.org>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  emacs-devel@gnu.org
> Date: Wed, 17 Aug 2022 02:56:58 -0700
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Would it make sense to have the lite mode in core?
> 
> I don't think so; that would mean any use of ada-mode would cause a
> conflict in auto-mode-alist.

Why would they conflict?  Or, IOW, why wouldn't it be possible to make
them not conflict, assuming that no one will activate both modes in
the same buffer?

Re: New ELPA package ada-lite

[Stephen Leake]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stephen Leake <stephen_leake@stephe-leake.org>
>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  emacs-devel@gnu.org
>> Date: Wed, 17 Aug 2022 02:56:58 -0700
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Would it make sense to have the lite mode in core?
>> 
>> I don't think so; that would mean any use of ada-mode would cause a
>> conflict in auto-mode-alist.
>
> Why would they conflict?  Or, IOW, why wouldn't it be possible to make
> them not conflict, assuming that no one will activate both modes in
> the same buffer?

ada-mode does this:

(add-to-list 'auto-mode-alist '("\\.ad[abs]\\'" . ada-mode))


ada-lite-mode does this:

(add-to-list 'auto-mode-alist '("\\.ad[abs]\\'" . ada-lite-mode))


Whichever is done last ends up first in auto-mode-alist, and is the one
that (assoc ".ads" auto-mode-alist) returns.

See also Stefan's reply.

-- 
-- Stephe

Re: New ELPA package ada-lite

[Eli Zaretskii]

> From: Stephen Leake <stephen_leake@stephe-leake.org>
> Cc: monnier@iro.umontreal.ca,  emacs-devel@gnu.org
> Date: Wed, 17 Aug 2022 18:08:48 -0700
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Stephen Leake <stephen_leake@stephe-leake.org>
> >> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  emacs-devel@gnu.org
> >> Date: Wed, 17 Aug 2022 02:56:58 -0700
> >> 
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >> 
> >> > Would it make sense to have the lite mode in core?
> >> 
> >> I don't think so; that would mean any use of ada-mode would cause a
> >> conflict in auto-mode-alist.
> >
> > Why would they conflict?  Or, IOW, why wouldn't it be possible to make
> > them not conflict, assuming that no one will activate both modes in
> > the same buffer?
> 
> ada-mode does this:
> 
> (add-to-list 'auto-mode-alist '("\\.ad[abs]\\'" . ada-mode))
> 
> 
> ada-lite-mode does this:
> 
> (add-to-list 'auto-mode-alist '("\\.ad[abs]\\'" . ada-lite-mode))
> 
> 
> Whichever is done last ends up first in auto-mode-alist, and is the one
> that (assoc ".ads" auto-mode-alist) returns.

OK, and how is this a problem?  It's quite clear that the last one
will win, but that's not the situation I would like us to support.  I
would like Emacs to have some minimal support for Ada OOTB.  If a user
_also_ downloads and installs the larger package from ELPA, it is
expected that they will only have that larger mode for Ada files.

IOW, I still don't see any problem with that.

Re: New ELPA package ada-lite

[Stephen Leake]

[-- Attachment #1: Type: text/plain, Size: 4137 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I'd like to add a package ada-lite-mode to ELPA; code attached.  The
>> intent is to be a mode for Ada files that's easier to install than the
>> current ELPA ada-mode.
>
> 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.

Almost all of ada-lite-mode is duplicated in ada-mode, so it would make
sense to use ada-lite-mode in ada-mode. However, that means there would
always be conficting entries in auto-mode-alist.

If a user wants both modes available so they can decide on a
file-by-file basis which one to use, they'll have to change
auto-mode-alist before visiting a file, or change the mode after
visiting, or something similar.

Are there other modes in ELPA (or MELPA?) that support the same file
extensions? There are several packages that mention "Python", for
example (some in MELPA). I don't have all of ELPA checked out; perhaps
you can do a grep-find for auto-mode-alist?

>
> A few more comments about the code:
>

Accepted unless commented on here; thanks for the detailed review.

>> (defun ada-lite-syntax-propertize (start end)
>>   "For `syntax-propertize-function'.
>> Assign `syntax-table' properties in region START .. END.
>> In particular, character constants are set to have string syntax."
>>   ;; (info "(elisp)Syntax Properties")
>>   ;;
>>   ;; called from `syntax-propertize', inside save-excursion with-silent-modifications
>>   (let ((inhibit-read-only t)
>> 	(inhibit-point-motion-hooks t))
>
> `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? Can that be improved?

> And `inhibit-read-only` should already be t since we're within
> `with-silent-modifications`.

Perhaps the doc string for syntax-propertize-function should state that
it is called from within with-silent-modifications.

And the doc string for with-silent-modifications should state that it
sets inibit-read-only t.

Patch attached.

>
>>     (goto-char start)
>>     (save-match-data
>
> Why?

I suspect this is left over from an earlier version of ada-mode.

> I think
>
>     (syntax-propertize-rules
>      ("[^[:alnum:])]\\('\\)[^'\n]\\('\\)"
>       (1 "\"'")
>       (2 "\"'")
>      ("[^[:alnum:])]\\('\\)'\\('\\)"
>       (1 "\"'")
>       (2 "\"'"))
>
> would do basically the same, but:
>
> - Is there a specific reason why you preferred to code it by hand
>   (speed maybe?)

I was unaware of syntax-propertize-rules.

> 
> - 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.

> You could merge the two into:
>
>     (syntax-propertize-rules
>      ("[^[:alnum:])]\\('\\)\\(?:'\\|[^'\n]\\)\\('\\)"
>       (1 "\"")
>       (2 "\""))

I'll test with this.

>>   (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.

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

>> (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. 

-- 
-- Stephe

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: misc.diff --]
[-- Type: text/x-patch, Size: 1690 bytes --]

diff --git a/lisp/emacs-lisp/syntax.el b/lisp/emacs-lisp/syntax.el
index e1be301583..6b239c36c8 100644
--- a/lisp/emacs-lisp/syntax.el
+++ b/lisp/emacs-lisp/syntax.el
@@ -57,10 +57,12 @@ syntax-propertize-function
 It is the work horse of `syntax-propertize', which is called by things like
 Font-Lock and indentation.
 
-It is given two arguments, START and END: the start and end of the text to
-which `syntax-table' might need to be applied.  Major modes can use this to
-override the buffer's syntax table for special syntactic constructs that
-cannot be handled just by the buffer's syntax-table.
+It is given two arguments, START and END: the start and end of
+the text to which `syntax-table' might need to be applied.  It is
+called from within `with-silent-modifications'. Major modes can
+use this to override the buffer's syntax table for special
+syntactic constructs that cannot be handled just by the buffer's
+syntax-table.
 
 The specified function may call `syntax-ppss' on any position
 before END, but if it calls `syntax-ppss' on some
diff --git a/lisp/subr.el b/lisp/subr.el
index ca4d52535a..2b44a0316a 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -4608,7 +4608,8 @@ with-silent-modifications
 than cosmetic ones, undo data may become corrupted.
 
 This macro will run BODY normally, but doesn't count its buffer
-modifications as being buffer modifications.  This affects things
+modifications as being buffer modifications.  `inhibit-read-only'
+and 'inhibit-modification-hooks' are both t.  This affects things
 like `buffer-modified-p', checking whether the file is locked by
 someone else, running buffer modification hooks, and other things
 of that nature."

Re: New ELPA package ada-lite

[Rudolf Schlatte]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

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

For Julia, there's julia-mode which implements basic language support,
and julia-snail which adds a vterm-based REPL and other niceties.
julia-snail is implemented as a minor mode that the user activates via
the main julia-mode hook.

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

Re: New ELPA package ada-lite

[Stephen Leake]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> 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)?

Hmm. Maybe. Currently they are distinct modes because eglot uses the
mode to find the language server; ada-lite-mode allows for eglot, but
ada-mode provides many of the same facilities as eglot, and therefore
eglot should _not_ know about it.

The current entry in eglot-server-programs has ada-mode; that will
change to ada-lite-mode when this gets released. Unless we decide on a
different solution.

> 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.

I guess the long-term goal is to merge all features into one mode,
possibly as minor-modes, as you describe for javascript.

If each feature of ada-mode that conflicts with eglot is changed to a
minor mode, it can just be disabled, rather than deleted.

I'll experiment; I'll use ada-mode with eglot, and try to turn off
things that cause problems.

>> 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`).

Ok, I'll delete the flush-cache and see what happens.

-- 
-- Stephe

Re: New ELPA package ada-lite

[Stefan Monnier]

> I guess the long-term goal is to merge all features into one mode,
> possibly as minor-modes, as you describe for javascript.
>
> If each feature of ada-mode that conflicts with eglot is changed to a
> minor mode, it can just be disabled, rather than deleted.
>
> I'll experiment; I'll use ada-mode with eglot, and try to turn off
> things that cause problems.

You can probably start by disabling `ada(-minor)-mode` when `eglot-mode`
is enabled and vice-versa.  Then later you can try and experiment with
making them work at the same time (both to see to what extent it can
work and also to what extent it can be useful).


        Stefan

Re: New ELPA package ada-lite

[Felician Nemeth]

Hello Stephen,

> I'd like to add a package ada-lite-mode to ELPA; [...]
>
> This can be used as-is, in which case all you get is reserved word
> highlighting. Or it can be used with eglot and an Ada language server,
> which gives many more features (some of which ada-mode does not have).

It seems the AdaCore language server defined some exenenstions to the
protocol [1].  Have you thought about implementing these extensions on
top of Eglot?  Are they useful?  I implemented similar extensions in the
past, and some of ada extensions seem quite simple.  I've never written
a line of ada in my life, but I'm happy to help if you need it.

Felicián

[1]: https://github.com/AdaCore/ada_language_server/blob/master/doc/README.md

Re: [SPAM UNSURE] Re: New ELPA package ada-lite

[Stephen Leake]

Felician Nemeth <felician.nemeth@gmail.com> writes:

> Hello Stephen,
>
>> I'd like to add a package ada-lite-mode to ELPA; [...]
>>
>> This can be used as-is, in which case all you get is reserved word
>> highlighting. Or it can be used with eglot and an Ada language server,
>> which gives many more features (some of which ada-mode does not have).
>
> It seems the AdaCore language server defined some exenenstions to the
> protocol [1].  

Thanks for the reminder; I had forgotten about those.

> Are they useful? 

I'm not sure. After I get eglot working with ada-mode, I'll think about it.

-- 
-- Stephe

Re: New ELPA package ada-lite

[Fernando Oleo Blanco]

On 15.08.22 19:56, Stephen Leake wrote:
> I'd like to add a package ada-lite-mode to ELPA; code attached. The
> intent is to be a mode for Ada files that's easier to install than the
> current ELPA ada-mode.
>
> This can be used as-is, in which case all you get is reserved word
> highlighting. Or it can be used with eglot and an Ada language server,
> which gives many more features (some of which ada-mode does not have).
>
> Installing the AdaCore ada_language_server is easier than installing the
> executables for ada-mode; it can be done via Alire (https://alire.ada.dev/).
>
> --
> -- Stephe

Any news on getting this into ELPA?

Re: New ELPA package ada-lite

[Stephen Leake]

Fernando Oleo Blanco <irvise_ml@irvise.xyz> writes:

> On 15.08.22 19:56, Stephen Leake wrote:
>> I'd like to add a package ada-lite-mode to ELPA; code attached. The
>> intent is to be a mode for Ada files that's easier to install than the
>> current ELPA ada-mode.
>>
>> This can be used as-is, in which case all you get is reserved word
>> highlighting. Or it can be used with eglot and an Ada language server,
>> which gives many more features (some of which ada-mode does not have).
>>
>> Installing the AdaCore ada_language_server is easier than installing the
>> executables for ada-mode; it can be done via Alire (https://alire.ada.dev/).
>>
>> --
>> -- Stephe
>
> Any news on getting this into ELPA?

I ended up adapting ada-mode to be able to use eglot; I'm just releasing
that version now.

-- 
-- Stephe