unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stephen Leake <stephen_leake@stephe-leake.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel <emacs-devel@gnu.org>
Subject: Re: New ELPA package ada-lite
Date: Wed, 17 Aug 2022 02:50:54 -0700	[thread overview]
Message-ID: <86sflvfbb5.fsf@stephe-leake.org> (raw)
In-Reply-To: <jwvsflx2ww2.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Mon, 15 Aug 2022 15:04:56 -0400")

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

  parent reply	other threads:[~2022-08-17  9:50 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-15 17:56 New ELPA package ada-lite Stephen Leake
2022-08-15 19:04 ` Stefan Monnier
2022-08-16  2:25   ` Eli Zaretskii
2022-08-17  9:56     ` Stephen Leake
2022-08-17 12:04       ` Eli Zaretskii
2022-08-18  1:08         ` Stephen Leake
2022-08-18  6:33           ` Eli Zaretskii
2022-08-17  9:50   ` Stephen Leake [this message]
2022-08-17 10:56     ` Rudolf Schlatte
2022-08-17 11:49     ` Stefan Monnier
2022-08-18  1:23       ` Stephen Leake
2022-08-18  2:02         ` Stefan Monnier
2022-08-19 11:05 ` Felician Nemeth
2022-08-19 14:24   ` [SPAM UNSURE] " Stephen Leake
2023-01-05 22:53 ` Fernando Oleo Blanco
2023-01-07  0:38   ` Stephen Leake

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86sflvfbb5.fsf@stephe-leake.org \
    --to=stephen_leake@stephe-leake.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).