Hacker News Reader

Comment by sargstuff | Hacker News Reader

Company culture tends to drive the program architecture (appropriate or not).

Small developer discussion outside of company time (not related to company stuff) might help with team building and understanding the strengths/weakeness of those working with.

'Mastering EMACs'[1] would seem to cover the example complex text-editor.

Looking at & understanding open source projects may help both code & using other resources to understand the 'meta-data'/setup of a given project. aka cmake, git, X11 resource, unix OS, shell programming, etc

Quite a few open source programs/projects also have forums where questions can be asked/answer reguarding why/how things were done in a project. Also typically have additional resources/pointers to things program/project makes use of.

----

[1] : https://www.emacswiki.org/emacs/BooksAboutEmacs

View on HN

I haven't read mastering emacs, but reading about it gives me impression that it is more for using emacs?

Emacs is very much on the radar otherwise, and I have actually skimmed documentation for information about its architecture.

Yes, looking for link about history of emacs. As memory serves, EMACs was written using the common 80's approach (from scratch, in non-device independent ways because predates c 89 standard & modular libraries didn't exist). Currently, this is causing lots of headaches when trying to use/add/move things over to modern gui / standard modularized to avoid/minimize device dependence / leverage other projects useful to expand emacs)

Smaller project note: make was written as one shot thing with intend of about 5 people using it, hence decision to go with 'tab' and not space(s) at start of line.

Note how things are grouped / structured in emacs. (beyond the tree, aka implied surrounding environment, current abstraction level, abstraction level(s) below current abstraction level.

lisp (.) notation works for nice compact level notation aka outside (.) is parent environment, inside (.) is various levels of () abstraction, evaluating pair of () gives result of the () application evaluated. Where something like the bash shell, the (.) is what happens in the shell file, outside of the (.) is the command line environment, and inside () may be multiple nested shell file abstraction/other shell file references. Note: can extend the (.) concept to spreadsheets, where each cell in spread sheet is shell file & spreadsheet is "file directory".

Could check out how treesitter is used in vim/neovim vs. emacs. and/or 70's tex & nroff put together things.

ed fairly barebones editor, one step up from command line sed.

Slightly more modern approach, search engine term 'text editor written in ' adding language of choice/familiar with after 'in' aka 'text editor writtin in bash'. play around with source code.

What's the ide & code repository (with reports/code/"goals"/dev communication) being used? aka developer environment should take care of lot of non-code/code details that are needed for development, but not what the current developement focus is. aka focus using X11 for front end to database (vs. developing X11 gui library to use as front end).

lisp short notation, where in the (.) is the focus?

outside (.), result of some (.) nested in several (.) levels, or result of top (), or totally different top level ()?

Reply on news.ycombinator.com