recipes/general-close added

[andreas-roehler]

No description provided.

[andreas-roehler]

melpa was requested several times

See emacs-berlin/syntactic-close#2

[purcell]

Thanks. The symbol naming is a bit random in these files. There are prefixes like gen--, gen-, gc-- etc. -- the code should instead follow the elisp coding conventions and prefix all top-level symbols with general-close- (or general-close-- for package-private symbols).

[andreas-roehler]

Am 24.07.2015 um 14:41 schrieb Steve Purcell:

Thanks. The symbol naming is a bit random in these files. There are
prefixes like |gen--|, |gen-|, |gc--| etc. -- the code should instead
follow the elisp coding conventions
https://www.gnu.org/software/emacs/manual/html_node/elisp/Coding-Conventions.html
and prefix all top-level symbols with |general-close-| (or
|general-close--| for package-private symbols).

—
Reply to this email directly or view it on GitHub
#2958 (comment).

Done, thanks!

[purcell]

There's also some code which is creating and setting unprefixed top-level variables, e.g. (setq done (member (char-before) (list ?\t ?\n ?\ ?=))) here. You should be using (let ...) to set values locally for a block like that, and if you need to refer to them elsewhere (as you appear to here) then they should be declared as proper top-level defvars with the full package prefix.

[andreas-roehler]

Am 25.07.2015 um 00:42 schrieb Steve Purcell:

There's also some code which is creating and setting unprefixed
top-level variables,

Not really.

`done' is not a top-level variable, but let-bound by the top-level command.
Settings here should effect environment, can't introduce a local let.

e.g. |(setq done (member (char-before) (list ?\t ?\n ?\ ?=)))| here
https://github.com/emacs-berlin/general-close/blob/master/general-close-modes.el#L74.
You should be using |(let ...)| to set values locally for a block like
that, and if you need to refer to them elsewhere (as you appear to
here
https://github.com/emacs-berlin/general-close/blob/master/general-close-modes.el#L83)
then they should be declared as proper top-level |defvar|s with the
full package prefix.

—
Reply to this email directly or view it on GitHub
#2958 (comment).

The value is expected to be bound inside a let, it should not conflict
with parellel runs of general-close.

Can't savely use defvar AFAIU.

[purcell]

The value is expected to be bound inside a let, it should not conflict
with parellel runs of general-close.

Eww, right, I didn't notice that it was a let-bound parameter implicitly passed from the other file.

[andreas-roehler]

Am 25.07.2015 um 08:55 schrieb Steve Purcell:

Merged #2958 #2958.

—
Reply to this email directly or view it on GitHub
#2958 (comment).

Thanks a lot!