Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make *scratch* Emacs LIsp by default #690

Closed
tuhdo opened this issue Feb 25, 2015 · 16 comments
Closed

Make *scratch* Emacs LIsp by default #690

tuhdo opened this issue Feb 25, 2015 · 16 comments

Comments

@tuhdo
Copy link
Contributor

tuhdo commented Feb 25, 2015

@syl20bnr We shouldn't change it to Text. I guess it is because you want *scratch* to be something to temporary store text. However, we can always create a new temporary buffer by entering non-existent buffer name. Otherwise this behaviour should be documented.

@CestDiego
Copy link
Contributor

if it starts as emacs-lisp I think the startup would be much larger, because it has to load everything that comes to it..flycheck, w/e

@tuhdo
Copy link
Contributor Author

tuhdo commented Feb 25, 2015

Currently when *scratch* is in text-mode, after switching to it and insert "(", trying to delete the character with backspace gives me this error:

apply: Symbol's value as variable is void: smartparens-strict-mode [2 times]

@syl20bnr
Copy link
Owner

Why should I make it emacs-lisp ? If I'm a clojure programmer and don't hack lisp or don't hack lisp very often it makes no sense for me, I would prefer it to be in clojure-mode.

I cannot impose what scratch buffer must do to the user, moreover it makes the load time to increase as @CestDiego mentioned.

Setting the scratch buffer to a specific major-mode other than text is a user preference and should be set in the dotfile. We can improve the documentation on this point with a scratch section.

@syl20bnr
Copy link
Owner

For the bug you can open an issue, it is not related to scratch buffer.

@tuhdo
Copy link
Contributor Author

tuhdo commented Feb 25, 2015

The bug was caused when I was working with my C/C++ layer. It's fine now. And yes, I think there should be documentation about the scratch buffer behavior. It is because I use scratch buffer frequently to test Elisp code, so when Spacemacs surprised me when the scratch buffer is in text-mode.

@syl20bnr
Copy link
Owner

I reopen it to track the update to the documentation.

@StreakyCobra
Copy link
Contributor

Putting the following snippet:

(setq initial-major-mode 'ruby-mode)

in user-config or user-init doesn't work. It's probably because the buffer get's created between this and user-config. We can probably extract this as a variable if people need this functionality.

@d12frosted
Copy link
Collaborator

I don't like duplication of existing variables, that's why it would be nice to make sure that it's possible to configure existing variable. But if it's not really possible to make it safe - I don't mind having dotspacemacs-***.

What I fear is that if we want to support any major mode in scratch buffer - we should set it after layers are initialised. Things that should be tested:

  1. Setting it to org-mode should not force Emacs to load bundled version of org (it will hurt org layer).
  2. Setting it to ruby-mode should just set scratch buffer major mode to ruby.
  3. Setting it to not existing xxx-mode should just fall to text-mode.

@StreakyCobra
Copy link
Contributor

You're right, we should make possible for user to customize it. Definitively not "Beginner Friendly" anymore :-)

@TheBB
Copy link
Collaborator

TheBB commented Nov 17, 2015

Can we add a mechanism to revisit the scratch buffer after user-config and change the major mode, according to the value of initial-major-mode? That wouldn't require a new variable, and it would still let the user configure it in the config function. It would be safe with org as well.

@TheBB
Copy link
Collaborator

TheBB commented Nov 17, 2015

@sschuldenzucker
Copy link

@tuhdo, what solved the issue with the apply: Symbol's value as variable is void: smartparens-strict-mode for you? I'm gettings this everywhere since the most recent update (today).

@sam217pa
Copy link

https://github.com/sschuldenzucker I do too… kind of annoying, not being able to make a mistake in a text editor…

@syl20bnr
Copy link
Owner

I'm OK with an additional dotspacemacs variable for the scratch buffer, seems required here.
The default major-mode is set to text also to prevent to kick lazy-loading of some package at loading time. I guess that a sane default is to pretend that users don't use the scratch buffer and make no assumption of its content.

@wginolas
Copy link

I am also getting the apply: Symbol's value as variable is void: smartparens-strict-mode error in eshell, when I hit Backspace. After I disabled the "Enable smartparens globally." Toggle with "SPC t C-p" Backspace in eshell works again.

@TheBB
Copy link
Collaborator

TheBB commented Jan 11, 2016

It's now configurable in master. Closing.

@TheBB TheBB closed this as completed Jan 11, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants