emacs-elpa-diffs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[nongnu] elpa/scala-mode aaf1ed8 149/217: Readme update.


From: ELPA Syncer
Subject: [nongnu] elpa/scala-mode aaf1ed8 149/217: Readme update.
Date: Sun, 29 Aug 2021 11:31:02 -0400 (EDT)

branch: elpa/scala-mode
commit aaf1ed8b1af380240ed351cf2dc3ffd01beb7cb5
Author: Ivan Malison <IvanMalison@gmail.com>
Commit: Ivan Malison <IvanMalison@gmail.com>

    Readme update.
---
 README.md | 19 ++++++++++++++++---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/README.md b/README.md
index 796b5d3..0e52790 100644
--- a/README.md
+++ b/README.md
@@ -445,7 +445,10 @@ Multiple assignment to variables e.g.
 val a, b = (1, 2)
 ```
 
-are among the assignment types that are not currently supported.
+are among the assignment types that are not currently supported. In general
+the only types of definition that these functions are likely to support
+are ones that use only a single, simple (but possibly generic) identifier as 
+its identifer.
 
 ## imenu
 
@@ -460,7 +463,6 @@ functions, and as such, it shares their limitations.
 ## Other features
 - highlights only properly formatted string and character constants
 - indenting a code line removes trailing whitespace
-- imenu compatibility 
 
 ## Known issues
 
@@ -477,7 +479,18 @@ The indenter thinks the second occurrence of `foo` is the 
body of the while.
 To work around this, terminate the while with a semicolon,
 or put a blank line after it.
 
-`scala-syntax:end-of-definition` `scala-syntax:beginning-of-definition` 
+As mentioned above,
+`scala-syntax:end-of-definition` `scala-syntax:beginning-of-definition`
+don't properly handle any defintions that don't have a simple, single 
+identifier.
+Its likely that they will stumble when presented with some of the more advanced
+and obscure scala definitions out there.
+
+There also seems to be a strange bug with scala-modes2's `end-of-defun` 
integration
+where two functions are skipped instead of just one. 
`scala-syntax:end-of-definition`
+does not have this problem, so if you find this bug bothering you a lot
+you can bind whatever you normally bind to `end-of-defun` to
+`scala-syntax:end-of-definition` in scala mode to alleviate the issue.
 
 ## Future work
 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]