if the install script is going to use pry, it ought to install it

As part of the discussion in #57, it seems we've decided on a good branching scheme. I mentioned that we should probably go ahead and toss the scheme there into the CONTRIBUTING.md file, but in looking at the current version of this file, it seems less welcoming and more verbose than I'd hope for.

I think the opener can be a bit less terse and more friendly, and the "Options" section can probably be refactored to reduce the number of bullet points.

I'm just opening this issue for tracking, feel free to provide feedback.

This has been floating around my head for a while, and since we've been throwing a bunch of shit on the board lately, I thought I might as well get it out there.

The idea is basically that after we start we spin off a few processes that check to see if

1. any emacs packages need updating
2. dot is out of date
3. the loaded user config is out of date

If any of these are true, insert the results in a comment in *scratch*.

Thoughts @rye @samontea?

Task List:

• #66 Updating kotct/packup UI
• Creating kotct/dotup a dot function for updating dot configs with the UI from #66
• Creation of a unified update function kotct/up for both packages and dot configurations

One aspect of this project that we haven't really covered is shell configurations.

My plan is to imitate what we did with Emacs, but this time for a shell configuration.

Generally, the process to implement this is as follows:

• We would implement something like a ~/.profile file meant to be loaded independently of by which app, to normalize environment variables.
  • From this, we would move on to implementing a smarter and smarter configuration system so that it is more dynamic and smart.
  • We could consider implementing this with a large number of debugging traces that we can turn off when we're done but still use for testing.
• From this, we would implement some (much smaller) configurations for each of the different shells we use.

A question to be answered by @cg505, (also @Sammidysam, and @samontea):

• Should we set PS1? Or should that be user-configured locally?
  • If it should be set by the user, how? (cc #30)

I have not used helm and I was wondering if anyone else has. It seems like it does many of the same things as ido but in many cases it does them better. I was considering creating a branch to try it out.

This is something that I/someone needs to dig into at some point and update this issue with more info.

We do several prompts on startup (especially the first time) such as asking if packages want to be installed, asking about a default config, etc. These currently don't work when emacs starts headless (e.g. $ emacsclient -c -a "").

This is not a simple issue to solve, and thus is pretty low-priority. We would have to do something like stop startup, and put all remaining starup on after-make-frame-functions, and remove the hook it after it runs.

If and only if emacs is started in daemon mode, the initial theme is not loaded correctly, even if the user switches to another theme and back to the first. The issues are small: colors off, etc. I noticed when using material-theme as used in my config.
This is probably something to do with loading the theme before we have any connection to X or something. I have not had much time to investigate the issue.

If I switch to a user configuration hub and then back to my own with a syntax error, things break and Emacs complains that, for example if I switch from my own broken hub to cg505's, then try to switch to my own broken hub,

cg505-hub is not a currently loaded feature

This is something I'm using more and more, and I'd like to port it over from my personal configuration.

I have gotten the following warning since switching back to Emacs' development version.

Warning (package): Unnecessary call to ‘package-initialize’ in init file

It seems that our call of this is unnecessary.

The reason automatic package loading occurs after loading the init file is that user options only receive their customized values after loading the init file, including user options which affect the packaging system. In some circumstances, you may want to load packages explicitly in your init file (usually because some other code in your init file depends on a package). In that case, your init file should call the function package-initialize. It is up to you to ensure that relevant user options, such as package-load-list, are set up prior to the package-initialize call. This will automatically set package-enable-at-startup to nil, to avoid loading the packages again after processing the init file. Alternatively, you may choose to completely inhibit package loading at startup, and invoke the command M-x package-initialize to load your packages manually.

Given that we require any dependencies that we need to configure before configuring them, do we still need this call? Emacs is saying no.

It seems we haven't added support for sh-mode yet. That is a thing that should be done.

Known issues needing fixed:

• Spaces are always used

I think we should really look into improving some of the ways we interact with users. We should try to deal with edge cases in a smarter way, and generally clean up our code. How do we feel about using CI and tests? Testing our existing code might evoke good change in our codebase.

Task List:

• #61 Add testing framework and integration with Travis CI, using buttercup
• #75 Add coverage support and reporting to Coveralls using undercover
• Write tests for existing code
• Add linting support, fix linting issues, and check linting in Travis CI

we use ssh, as per emacswiki. but TRAMP itself claims scp is faster. who's right?

also TIL tramp supports adb, lol

It seems that we have not set up tracking on this to make variable values consistent. Nor have we set up SQL support, which is part of web-mode.

Since web development is such a big part of my life, it's a damn shame that I haven't fixed this to this point.

load-prefer-newer tells load to pick the .el file if it is newer than the .elc (and vice versa, of course). This can incur a speed penalty. We need this on for emacs lisp that we write, since there is no guarantee that the compiled version is the most recent. We have been let-binding load-prefer-newer to t when loading hubs to avoid this issue. However, it seems likely that that binding does not affect autoloads. I don't see any simple/non-hacky way to deal with correctly loading the right version of autoloaded files in our config without simply setting load-prefer-newer globally. I don't expect the speed penalty to be significant. Thoughts?

This is annoying. We shouldn't have this file be loaded into a buffer on startup.

this is note to future me. would be a stylistic improvement

As this becomes a more major project with actual potential for wider usage, it would be good to set up our licensing and everything correctly.

In CI, we're getting errors now with assert not being defined. We should definitely have that defined, and I think it's probably something up with byte-compilation or how we're loading cl to do assertions.

For reference, here is the first build where this showed up, Travis build #139.

Eventual support for smartparens is a must at some point. It should be on the radar.

In CI, Emacs is failing to start up in certain cases due to line 3 in user-config-system.el as of 5ad51d1.

This issue existed prior to this commit as well, but I'm too lazy to bisect.

Since it looks like we don't even use it in that file, I think the fix is to remove that line and not require git.

Provide some way to have a machine-specific config. Could be used for things like setting executable locations.

todo: fill out this issue with actual information

scroll-bar-mode is undefined in emacs-nox. this causes the emacs config to fail.

In #51 we concluded we were not correctly warning the user when they did not have have the EditorConfig executable installed. This was fixed in PR #52. However, I think this needs reevaluated. The main reason is that the emacs package for EditorConfig has fallback parsing support that doesn't depend on the binary and seems to be fully functional. If we have the binary, we should use it, but it doesn't seem to make sense to me to warn the user every time they start up if they don't have a binary that they don't even really need.

Other relevant issues/PRs: #10 #18.

One of the stated goals of our Emacs configuration is to:

• Have a focus on excellent support for individual languages.

The problem of supporting many languages is a complicated one. For the community, the workload required to support m languages on n editors is O(m n), as you might expect.

LSP, the Language Server Protocol, aims to turn this from O(m n) to O(m + n), by offloading general tasks to a separate process that is implemented for the specific language. In this way, an editor only needs to implement bindings to connect to a language server and handle its responses, and the language server can be provided by those who are familiar with the language.

Is there interest in adopting lsp-mode? It has nice integrations with flycheck and company-mode too.

Here's an example of what lsp-ui presents in rust-mode. Quite rich!

Version self-checking against a remote is a feature that we should add to this project going forward, and the ability to do this quickly and asynchronously is critical to implementing a clean user-facing interface.

In general, I want to implement a suite of configuration files and shell scripts in this project for self-checking the current version installed against some remote. In the event of an outdated installation, the user would be prompted to update. This brings about the following questions:

• Do we want to support non-standard installation of dot? I say no, and I'm pretty sure all of the other collaborators would agree. Anyone who does not install the project through a standard installation vector assumes their own responsibility for keeping things running stably. Standard installation vectors are as follows:

  1. git clone-ing our project onto a client machine. (--shallow is within the realm of possibility, which may result in loss of tags.)
  2. Downloading a tarball of the project at a given release.
  • In both cases above, the installation will include a full bundle of the .emacs.d tree and any shell configurations we bring in, as well as the central VERSION file at the root of the project. This can be a good fallback.

• When do we want to prompt people to update dot? I say: every time the user starts a dot component, this self-check should execute, and in long-running situations e.g. Emacs being open for days on end, daily timers should be run also. We should store the last update check timestamp in a readable file that everything can easily parse, so that multiple checks don't happen on top of each other.

• How do we want to execute remote scripts?

In my daily life, I walk around a lot. Emacs opens recentf a bunch, but it seems like it never really writes it to disk. (Evidenced by the fact that #recentf# is always left over in ~/.emacs.d except when the 5-minute #'recentf-save-list timer gets run.)

This is bad, because Emacs has support for preventing simultaneous edits, and when I change networks my hostname changes. Emacs then blocks my workflow and asks me if I want to steal the lock from myself. This is highly frustrating.

So, should we: (a) disable interlocking support entirely, via setting create-lockfiles to nil globally, or (b) do something more intelligent? I'm going to leave this to @cg505 because I have never used recentf before.

We should start thinking about versioning this using SemVer. The two questions I can think of are:

• Do we want to version this project? Or should this be rolling-release?
  • If so, what will be our indication that we are ready to release version 1?

This might affect our update-checking strategy for #56; users could also use a variable to decide whether they only want to use the latest release or the Git HEAD. (master in our case)

If we decide that we already passed a point where the project could be considered at v0.x.y, we can go back and make releases now for those points in history, and I can do that.

I'm thinking M-x kotct/user-update-config should behave a lot like C-x C-z in that it should ask the user for a username to fetch rather than just doing the current one. I could be wrong about this one, however.

Editorconfig overrides existing language code style settings in favor of project defined style guides in the form of .editorconfig file. This package does require an external dependency for the emacs package. We need to indicate to the user that they need to install this dep.

See the help for variable display-line-numbers in emacs 26.

At this point we should maintain compatibility with emacs 25, but if we can use the builtin line numbers, we should, since they are faster and better.

There's ace-jump stuff in both behavior/text.el and behavior/ace-jump.el. We need to consolidate. Personally, I think we should go for text.el.

Making the packup buffer interactive to allow for the user to more easily select a subset of the packages that they wish to update.

It would also help us prepare for the work necessary to complete #56. This can be considered party of that issue.

Acceptance Criteria:

• Must allow for user to select packages to update w/i a read only buffer
• Must provide help instructing users how to interact w/ the read only buffer

By default dired is unbound to a keycombo in emacs. I think we should bind it to C-x C-d because list list-directory is just a less useful version of dired. Any opposition?

Ideally, it'd either only print messages on success if that success status was new, (previous builds had failed) or just not print success messages at all.

ace-jump-mode is deprecated, and avy's features are a superset

We should add a code of conduct. My default choice is the Contributor Covenant.

Add support for .editorconfig files. See http://editorconfig.org/.

I think the ability to write easy tests is important.

lisp/code/languages/sh.el requires indentation, because it uses some features from lisp/code/indentation.el. However, when the tests were run in a sterile environment, (i.e. presumably with a bad load-path) there were problems.

So kotct/load-corresponding calls kotct/quietly-load-file and loads the file directly. It's just a matter of features being unable to be loaded. Can we set load-path somehow so that it covers all possible things that our tests can require?

This can be done via simply adding gitignore-mode, gitattributes-mode and gitconfig-mode to our list of dependencies.

The README file is a little bit verbose. Ideally, it should just include some basic stuff. Principles could be extracted to the Wiki or to another .md file.

Open to feedback and ideas.

Let's think about user configurations—they were a key feature of kotct.emacs because they enabled people to quickly switch configurations.

We should think about how we're gonna do this here. @cg505, got any ideas?

I think I'm against having all of this stuck here in this repository, though. I think having local hubs in a local emacs directory is a good plan—they could be git submodules of a shared but separate git repository which could get updated by an emacs command, for instance.

This needs more investigation, but it seems like our current approach in packup for checking/installing updates disregards package-archive-priorities (set in lisp/package/repositories.el). Namely, I see many packages on my system are installed from MELPA despite also being available in MELPA Stable (which has a higher priority).

This may be best wrapped into #84 (which would be lovely to finally get finished up when someone has a change).

Emacs currently seems configured to add newlines at EOF sometimes, but not to all files. I think we should make it add newlines to all (text) files, since all text files will get griped-about by Git/VC if they don't have newlines at the end.

That's also a pretty standard thing, too.

Acceptance Criteria:

• Files are saved with a newline at EOF by default

As it stands, the font setting functions are not fault-tolerant at all. If a font does not exist on the system, there is simply no error except the one raised by Emacs itself, which then halts the init process. For instance, the default font in my configuration is Fira Code, but this font is not installed on some machines that I work on, and I have to make local changes to my configuration to prevent a failure in loading.

I intend to work on this one—it will involve defining a pre-defined font hierarchy alist—as users add fonts, they can prepend to this list cons cells of the form ("Font Family Name" . default-size). We can also write defuns for interacting with this list.

This project intends to be a wide-ranging set of dotfiles. Currently it only contains emacs (although that's doing a pretty good job). As my primary shell, I use fish and hope to move the base of my configuration into this repo. Fish configuration doesn't really work in the same way emacs does in that you can configure it from the CLI instead of from mostly static config files (think set -U). I also use fisherman which work by creating symlinks into your config directory instead of creating a separate system that is loaded by your config (like in emacs with the elpa directory). These all pose challenges to a dot-style fish config that I am not sure how to solve. I don't even know if anyone else using this project also uses fish.

Our labels are somewhat unspecific and sad. If we can break things up into more component-wise labels and have priority labels, and use a labelling scheme like Hyper's, I think it'd be much easier to label issues.

Below are listed the different labelling groups and label names which I have created.

Concerns

The Concerns set of labels is used for demarcating the scope of the Issue or Pull Request to which they are assigned.

• Concerns: Dot
  • For Issues concerning the project as a whole
• Concerns: Emacs Configuration
  • For Issues concerning the Emacs Configuration as a whole (but not the entire project, Dot.)
• Concerns: Emacs/tree/behavior
  • For Issues concerning stuff in the behavior tree of the Emacs configuration
• Concerns: Emacs/tree/code
  • For Issues concerning stuff in the code tree of the Emacs configuration
• Concerns: Emacs/tree/file
  • For Issues concerning stuff in the file tree of the Emacs configuration
• Concerns: Emacs/tree/package
  • For Issues concerning stuff in the package tree of the Emacs configuration
• Concerns: Emacs/tree/user
  • For Issues concerning stuff in the user tree of the Emacs configuration
• Concerns: Emacs/tree/visual
  • For Issues concerning stuff in the visual tree of the Emacs configuration

Is

The Is set of labels is used to describe the status or quality of the Issue or Pull Request to which they are assigned.

• Is: Blocked
  • For Issues or Pull Requests that cannot be continued until another Issue or Pull Request is resolved
• Is: Deferred
  • For Issues or Pull Requests that are side-lined until further notice (see: Is: On Hold for another option)
• Is: Duplicate
  • For Issues or Pull Requests whose scope and concerns match an extant Issue or Pull Request that has not yet been resolved
• Is: Invalid
  • For Issues or Pull Requests that are poorly-written or otherwise deemed invalid
• Is: Not Fixable
  • For Issues which cannot be fixed
• Is: On Hold
  • For Issues or Pull Requests that are side-lined but may be resumed soon (see: Is: Deferred for another option)
• Is: Question
  • For Issues that are formulated as questions and are not direct requests
    • A Question label might be used for something hypothetical, but a separate issue should be opened once a decision is reached to specifically track the progress towards resolving the decision.
  • Note: This is not a label of the Type set because that set is specifically designated for

Needs

The Needs set of labels is used to describe is used to describe those Issues or Pull Requests which need further action in order to proceed.

• Needs: Discussion
  • For Issues or Pull Requests that need discussion in order to proceed
• Needs: Implementation
  • For Issues or Pull Requests that need (further) implementation to take place in order to proceed
• Needs: Investigation
  • For Issues or Pull Requests that need (further) investigation to take place in order to proceed
• Needs: Refactoring
  • For Issues or Pull Requests that need (further) refactoring to take place in order to proceed
• Needs: Research
  • For Issues or Pull Requests that need (further) research to take place in order to proceed

Priority

The Priority set of labels is used to describe the approximate priority of the Issue or Pull Request to which they are assigned.

• Priority: Critical
  • For Issues or Pull Requests considered to be at extremely high priority
    • e.g. Issues or Pull Requests where direct action is required to solve problems
• Priority: High
  • For Issues or Pull Requests considered to be at high priority
    • e.g. Issues or Pull Requests where direct action is strongly preferred over other Issues or Pull Requests
• Priority: Medium
  • For Issues or Pull Requests considered to be at medium priority
    • e.g. Issues or Pull Requests where direct action is weakly preferred over other Issues or Pull Requests
• Priority: Low
  • For Issues or Pull Requests considered to be at low priority
    • e.g. Issues or Pull Requests where direct action is not preferred over other Issues or Pull Requests

Type

The Type set of labels is used to describe the type of thing that is concerned by the Issue or Pull Request to which they are assigned.

• Type: Bad Code Style
  • For Issues concerning bad code style
• Type: Bad Feature
  • For Issues concerning bad features (see: Type: Bug for another option)
    • e.g. Issues or Pull Requests where existing code improperly uses the system
• Type: Bad Implementation
  • For Issues concerning bad implementation of a feature
• Type: Bad Performance
  • For Issues concerning bad performance
• Type: Bug
  • For Issues concerning bugs (see: Type: Bad Feature for another option)
    • e.g. Issues or Pull Requests where the system influences bad behavior in the codebase

Ungrouped

These labels are specifically ungrouped so that they can be searchable by API bots.

• Help Wanted
  • Anything where outside help is wanted

If a theme has already been loaded, kotct/switch-to-theme just disables the current theme and enables the new one.

This is problematic, because then kotct/switch-to-theme will always just re-enable the current theme. If, for instance, someone wants to customize solarized, (like turning off the variable-pitch in headings, as I prefer) they have no way of doing this. This could be rectified by adding an optional argument to kotct/switch-to-theme that always loads the theme.