7 ms·

Learn Emacs and then you can save hours of work doing anything. All you do is learn how to write Elisp Macros. And then you automate your knowledge. Think of i

by kamaal 8y ago

Learn Emacs and then you can save hours of work doing anything. All you do is learn how to write Elisp Macros. And then you automate your knowledge. Think of it like programming a text pad(s)(Like how excel is programming a list(s) of cells). You realize that the text buffer is your programming environment, with cursor movement as your basic control, and text output as your end goal. Then of course other programmatic facilities apply. Only recently wrote a piece of Elisp code at work, that takes a file, does a bit of error analysis and gives me offending lines and other inputs like ids. I take them in a buffer and do all kinds of set operations(intersection etc) from inputs in other buffers(Elisp code for that too). Then take them and have Elisp generate a email message for me(Again Elisp code to do this). I just copy paste and send it to respective stake holders. And I'm a novice who barely started with Emacs. I only imagine what I can do when I get fully proficient with it. It's like automating yourself. I guess we are only lucky our work happens to be mostly in text and we get to use emacs and vim(vim macros are just insane), just like accountants can put spreadsheets to crazy use as their work happens to deal with tables.

ashton314 8y ago
I feel like the ease with which one can write keyboard macros in Emacs is an often overlooked feature. Saves me so much work very day.
oblio 8y ago
Yeah, but you're basically just programming. Does Emacs really matter to what you listed? You could do all of that with Python and any programming editor.
- kamaal 8y ago
  You have basically do programming to do anything anywhere. There is no magic. >>You could do all of that with Python and any programming editor. Perl is better at these text manipulation things than Python. Lisp will be around for a lot of time than these languages. Though I expect Perl to be around too. But then vim is literally a kind of VisualPerl. Emacs feels like VisualLisp. Before learing Elisp I was writing tons of Perl scripts to tasks like these. Perl is just insanely good at all things text. But Perl doesn't have Lisp like Macros. And eventually you realize you can weaponize Macros to all kinds of things you can't do in Perl. In short Elisp is better at a few things than Perl.
  - oblio 8y ago
    > Lisp will be around for a lot of time than these languages. Are you sure about that? Lisp is old, and it has survived many old languages. But many of those were from the Computer Science/IT early teens age... Now CS/IT is quite mature. Mainstream languages, especially Open Source ones, will probably outlive us both. Even Perl ^.^
    - TeMPOraL 8y ago
      > But many of those were from the Computer Science/IT early teens age... Nah, that's when the maturing process happened; what we have today is mostly middle-age crisis, running in circles with occasional small step forward. Lisp will survive because it's essentially the fundamental core of programming. When you're writing Lisp, you're essentially writing an AST. The elegance, flexibility and powerfulness of this is exactly why every new runtime that shows up gets a Lisp made for it.
- aidenn0 8y ago
  "any programming editor." Most editors, even most of those with a programmable bent are not very malleable. I looked into improving indentation support for common lisp in other editors, and for editors not named "vim" or "emacs" the support was incredibly poor. For most, indentation was 100% builtin, so the only way to change the indentation was to either modify the editor itself (i.e. not a plugin), or install a plugin that hooked into the return key. Usually this was only doable from C. In addition, most of the elisp standard library is specifically for manipulating buffers of text; perl is the only language I've used that's could be argued to be better.
- TeMPOraL 8y ago
  The same way the Web Browser seems to be the best runtime for multimedia documents and graphical UIs, Emacs is arguably the best runtime for code operating on text, and for text-based user interfaces (not just 1D CLI, but also 2D). So yes, you could do it in any programming language, but Emacs gives you a powerful environment tailored for text-based work, and geared for full interoperability. Where on the Web you can barely get two pieces of software to talk to each other (and that's only until Chrome security team removes the trick you've used), in Emacs the features you create compose almost seamlessly with other features, both built-in and written by other users.
YetAnotherNick 8y ago
I have seen comments like this so many times, yet I can't think of much things in which emacs can help. I have 10s of keyboard shortcut in vim, but all of the steps are just combination of keys or passing selection to unix command. I can do all of the things in most programmable editor. The thing you described(error analysis) can be done in any language and I would have done in vim and wrote a shell script. It doesn't require any extensibility from editor side. I know how extensible emacs is, but there are very very few examples that requires this. Secondly the argument that lisp is better for text processing is not even relevant. You can install lisp compiler and use it with most editor if we are just passing the input into it.
- alpaca128 8y ago
  I feel exactly the same. Emacs is powerful, but basically everything it can do is also possible with Vim + Bash, and as both can be combined productively I saw no reason to use Emacs. In the end it doesn't matter if e.g. a document is compiled within Emacs or with a Vim shortcut that calls Pandoc in the background.
- kamaal 8y ago
  >>The thing you described(error analysis) can be done in any language and I would have done in vim and wrote a shell script. Exactly. The difference between Emacs and Vim cultures is, in vim you use shell and programs(like sed, awk, perl etc) as a kind of assorted set of tools to build what you want. Emacs gives you all that in one nice integrated package. If I'm not wrong this was also originally a difference between Unix and Lisp cultures. In Lisp you had the operating system boot to a Lisp REPL. In unix you have it boot to a shell. Then one good thing about lisp is the list syntax helps you exchange code and data in a proper structure. Whereas in shell you have to understand the structure of what you are passing around(Text). Which is why after a while you just have to write a Perl script to get things done. Error analysis is just one thing. Once you start building your utils, in Elisp, you just continue to use them together as a part of a larger workflow. In Unix you can do the same, but it will take you a lot of Perl and shell scripts. >>I have 10s of keyboard shortcut in vim, but all of the steps are just combination of keys or passing selection to unix command. Same in Emacs. When using vim you still have to commit a few things to Muscle memory, you have to learn movements, you have to learn modes. And then learn to use them with registers and macros. You do the same in Emacs. >>I can do all of the things in most programmable editor. Vim is a very nice editor. And I still use it a lot. But Emacs is a editor and beyond. I like to describe Emacs as an Editor and a very good programming system, which offers you way to program anything that comes in the domain of programmatically controlling a text buffer. >>I know how extensible emacs is, but there are very very few examples that requires this. I though the same way, but the use cases keep increasing once you start using it. It's really like saying spreadsheets are useless because you can iterate lists over a for loop and do what you like. Its only when you start using features like Pivot table, What-if, Vtables etc do you begin to see how powerful it can get. Some times it also requires changing the way you think about a tool to get it right. Once you start using it you begin to see all kinds of curious cases where it can be put to use. I've even seen(in YouTube) cool uses of Elisp Macros and Clojure macros stitched together to make Emacs generate Clojure code. Then plugins like aggressive-indent-mode and paredit just make writing code a bit like uttering your thought at the speed it occurs. You can also use Elisp to make debugging easy, or generate templates of code or do various other things. These are just very basic things, the possibilities are endless. >>Secondly the argument that lisp is better for text processing is not even relevant. You can install lisp compiler and use it with most editor if we are just passing the input into it. So basically you are suggesting I re-invent emacs itself? Because that's what installing a Lisp compiler and building text manipulation APIs means. Why should I do it, when the community has spend more than 5 decades doing it for me.
TeMPOraL 8y ago
Seconded. It's fair to say that almost any imaginable task involving mainly text - including many UIs - could be done better in Emacs. For instance, for my freelancing I track both tasks and time spent in Org Mode. I wrote myself a little bit of Elisp that, when invoked with the name of a customer, turns my Org Mode agenda into a table with line items for an invoice. I've been copying that into my invoice LaTeX template for a while, but recently I've been working on finishing the Elisp code: the end goal is to have a three-step process: 1) Press a key to generate a table with invoice line items and another with all other data that goes into the invoice. 2) Review the table, adjusting as necessary (e.g. rounding off stray minutes). 3) Press a key for Emacs to take these tables, fill a LaTeX template according to their contents, generate an invoice and file it in appropriate location. At this point I have 1) and 2) fully working, and 3) missing only the "fill template" and "refile result" steps, which are rather trivial to add. I'll release this publicly when I'm done. The current solution is somewhat specific to invoicing for services according to my country's regulations, but it shouldn't be too hard to make it universal (I'd love some help here, especially in form of examples of invoices for other countries). Did I spend more time on it that I would if I used a web tool for invoices? Yes. Do I expect to ultimately get ahead on this solution? Maybe. Is it worth it? The interface (read: an org-mode document invoking some elisp) is already more fluid than any web tool I've ever seen, and I don't need to be on-line - so a huge YES!
- shoover 8y ago
  Interesting use of orgmode as a database. How does it work? Does that use a built in agenda functionality or are you calling lower level org functions to query your agenda files and enumerating the results to generate the table as text in another buffer?
  - TeMPOraL 8y ago
    I use proper org-mode functions to query the built-in agenda and then group entries by org-mode tags. My code expects a configuration that maps tags to their line item names (as on invoice), hourly rates and applicable tax. I use this to output a dynamic[0] table like this: | Tag | Invoice line name | Hours | Rate | Net | VAT % | VAT amount | Total | |-----------------+-----------------------+-------+-------+--------+-------+------------+--------| | meeting | Meetings | 10 | 12.00 | 120.00 | NP | 0.00 | 120.00 | | procrastinating | Important tasks | 20 | 13.00 | 260.00 | NP | 0.00 | 260.00 | | hn | Other important tasks | 40 | 14.00 | 560.00 | NP | 0.00 | 560.00 | | coding | Occasional code | 3 | 15.00 | 45.00 | NP | 0.00 | 45.00 | |-----------------+-----------------------+-------+-------+--------+-------+------------+--------| | Totals | - | 73 | - | 985.00 | - | 0.00 | 985.00 | #+TBLFM: @>$3=vsum(@2..@-1)::@>$5=vsum(@2..@-1);%.2f::@>$7=vsum(@2..@-1);%.2f::@>$8=vsum(@2..@-1);%.2f::$5=$3*$4;%.2f::$7=if(typeof($6) < 10, $5*$6, 0);%.2f::$8=$7+$5;%.2f The #+TBLFM: line at the bottom is org-mode spreadsheet functionality; it ensures I can modify the table text in-place, and just press C-c C-c to recalculate all values in it. I generate a similar table with data for invoices; some taken from my configuration, some computed (e.g. invoice number is generated by looking at filenames of previous invoices; sale date and service period are estimated from current date and the time range you specified when generating line items table, etc.). The code for generating above table is hand-crafted. While org-mode provides you a generator for agenda tables based on TODO item name - see [1], I had to write similar feature that aggregated time by org-mode tags. I used [2] as a reference, but essentially wrote my own implementation. Surprisingly, it turned out to be almost trivial. Then, it's simply a matter of turning those two org-mode tables into an elisp list of keys and values. This I accomplish using a simple elisp that uses built-in Emacs calls: (defun trc-invoicing--named-table-to-lisp (name) "Convert a named org mode table in the current buffer into a list. The function finds a table named `NAME', passes it through `ORG-TABLE-TO-LISP', and return the result. Refer to the documentation of `ORG-TABLE-TO-LISP' for info about result's shape." (save-excursion (goto-char (point-min)) (search-forward (format "#+NAME: %s" name)) (forward-line) (org-table-to-lisp))) Then it's a matter of populating a LaTeX template with extracted values, invoking pdflatex, and copying the resulting PDF in an appropriate place. That last part I yet have to finish. It's the biggest piece of elisp I wrote since Nyan Mode, but all in all, I find it surprisingly easy to code for Emacs. Availability of source code, extensive in-editor documentation and built-in source-level debugger make this process pretty pleasant. -- [0] - Org Mode has a concept of "dynamic blocks". You type in #+BEGIN: blockname some params, and then using C-c C-c on it causes Org Mode to invoke an elisp function named org-dblock-write:blockname. The called function is then responsible for outputting contents of the dynamic block. [1] - http://orgmode.org/manual/The-clock-table.html http://orgmode.org/manual/The-clock-table.html [2] - https://gist.github.com/tsu-nera/d9ffa6a51a6e7bdb957b https://gist.github.com/tsu-nera/d9ffa6a51a6e7bdb957b
shoover 8y ago
I often get stuck somewhere between a one-off keyboard macro and finding a pre-written full-blown mode but resist learning the techniques and functions needed to do this powerful in between workflow automation. Care to share a snippet?

by kamaal 8y ago

ashton314 8y ago

I feel like the ease with which one can write keyboard macros in Emacs is an often overlooked feature. Saves me so much work very day.

oblio 8y ago

Yeah, but you're basically just programming. Does Emacs really matter to what you listed? You could do all of that with Python and any programming editor.

kamaal 8y ago
You have basically do programming to do anything anywhere. There is no magic. >>You could do all of that with Python and any programming editor. Perl is better at these text manipulation things than Python. Lisp will be around for a lot of time than these languages. Though I expect Perl to be around too. But then vim is literally a kind of VisualPerl. Emacs feels like VisualLisp. Before learing Elisp I was writing tons of Perl scripts to tasks like these. Perl is just insanely good at all things text. But Perl doesn't have Lisp like Macros. And eventually you realize you can weaponize Macros to all kinds of things you can't do in Perl. In short Elisp is better at a few things than Perl.
- oblio 8y ago
  > Lisp will be around for a lot of time than these languages. Are you sure about that? Lisp is old, and it has survived many old languages. But many of those were from the Computer Science/IT early teens age... Now CS/IT is quite mature. Mainstream languages, especially Open Source ones, will probably outlive us both. Even Perl ^.^
  - TeMPOraL 8y ago
    > But many of those were from the Computer Science/IT early teens age... Nah, that's when the maturing process happened; what we have today is mostly middle-age crisis, running in circles with occasional small step forward. Lisp will survive because it's essentially the fundamental core of programming. When you're writing Lisp, you're essentially writing an AST. The elegance, flexibility and powerfulness of this is exactly why every new runtime that shows up gets a Lisp made for it.
aidenn0 8y ago
"any programming editor." Most editors, even most of those with a programmable bent are not very malleable. I looked into improving indentation support for common lisp in other editors, and for editors not named "vim" or "emacs" the support was incredibly poor. For most, indentation was 100% builtin, so the only way to change the indentation was to either modify the editor itself (i.e. not a plugin), or install a plugin that hooked into the return key. Usually this was only doable from C. In addition, most of the elisp standard library is specifically for manipulating buffers of text; perl is the only language I've used that's could be argued to be better.
TeMPOraL 8y ago
The same way the Web Browser seems to be the best runtime for multimedia documents and graphical UIs, Emacs is arguably the best runtime for code operating on text, and for text-based user interfaces (not just 1D CLI, but also 2D). So yes, you could do it in any programming language, but Emacs gives you a powerful environment tailored for text-based work, and geared for full interoperability. Where on the Web you can barely get two pieces of software to talk to each other (and that's only until Chrome security team removes the trick you've used), in Emacs the features you create compose almost seamlessly with other features, both built-in and written by other users.

YetAnotherNick 8y ago

I have seen comments like this so many times, yet I can't think of much things in which emacs can help. I have 10s of keyboard shortcut in vim, but all of the steps are just combination of keys or passing selection to unix command. I can do all of the things in most programmable editor. The thing you described(error analysis) can be done in any language and I would have done in vim and wrote a shell script. It doesn't require any extensibility from editor side. I know how extensible emacs is, but there are very very few examples that requires this. Secondly the argument that lisp is better for text processing is not even relevant. You can install lisp compiler and use it with most editor if we are just passing the input into it.

alpaca128 8y ago
I feel exactly the same. Emacs is powerful, but basically everything it can do is also possible with Vim + Bash, and as both can be combined productively I saw no reason to use Emacs. In the end it doesn't matter if e.g. a document is compiled within Emacs or with a Vim shortcut that calls Pandoc in the background.
kamaal 8y ago
>>The thing you described(error analysis) can be done in any language and I would have done in vim and wrote a shell script. Exactly. The difference between Emacs and Vim cultures is, in vim you use shell and programs(like sed, awk, perl etc) as a kind of assorted set of tools to build what you want. Emacs gives you all that in one nice integrated package. If I'm not wrong this was also originally a difference between Unix and Lisp cultures. In Lisp you had the operating system boot to a Lisp REPL. In unix you have it boot to a shell. Then one good thing about lisp is the list syntax helps you exchange code and data in a proper structure. Whereas in shell you have to understand the structure of what you are passing around(Text). Which is why after a while you just have to write a Perl script to get things done. Error analysis is just one thing. Once you start building your utils, in Elisp, you just continue to use them together as a part of a larger workflow. In Unix you can do the same, but it will take you a lot of Perl and shell scripts. >>I have 10s of keyboard shortcut in vim, but all of the steps are just combination of keys or passing selection to unix command. Same in Emacs. When using vim you still have to commit a few things to Muscle memory, you have to learn movements, you have to learn modes. And then learn to use them with registers and macros. You do the same in Emacs. >>I can do all of the things in most programmable editor. Vim is a very nice editor. And I still use it a lot. But Emacs is a editor and beyond. I like to describe Emacs as an Editor and a very good programming system, which offers you way to program anything that comes in the domain of programmatically controlling a text buffer. >>I know how extensible emacs is, but there are very very few examples that requires this. I though the same way, but the use cases keep increasing once you start using it. It's really like saying spreadsheets are useless because you can iterate lists over a for loop and do what you like. Its only when you start using features like Pivot table, What-if, Vtables etc do you begin to see how powerful it can get. Some times it also requires changing the way you think about a tool to get it right. Once you start using it you begin to see all kinds of curious cases where it can be put to use. I've even seen(in YouTube) cool uses of Elisp Macros and Clojure macros stitched together to make Emacs generate Clojure code. Then plugins like aggressive-indent-mode and paredit just make writing code a bit like uttering your thought at the speed it occurs. You can also use Elisp to make debugging easy, or generate templates of code or do various other things. These are just very basic things, the possibilities are endless. >>Secondly the argument that lisp is better for text processing is not even relevant. You can install lisp compiler and use it with most editor if we are just passing the input into it. So basically you are suggesting I re-invent emacs itself? Because that's what installing a Lisp compiler and building text manipulation APIs means. Why should I do it, when the community has spend more than 5 decades doing it for me.

TeMPOraL 8y ago

Seconded. It's fair to say that almost any imaginable task involving mainly text - including many UIs - could be done better in Emacs. For instance, for my freelancing I track both tasks and time spent in Org Mode. I wrote myself a little bit of Elisp that, when invoked with the name of a customer, turns my Org Mode agenda into a table with line items for an invoice. I've been copying that into my invoice LaTeX template for a while, but recently I've been working on finishing the Elisp code: the end goal is to have a three-step process: 1) Press a key to generate a table with invoice line items and another with all other data that goes into the invoice. 2) Review the table, adjusting as necessary (e.g. rounding off stray minutes). 3) Press a key for Emacs to take these tables, fill a LaTeX template according to their contents, generate an invoice and file it in appropriate location. At this point I have 1) and 2) fully working, and 3) missing only the "fill template" and "refile result" steps, which are rather trivial to add. I'll release this publicly when I'm done. The current solution is somewhat specific to invoicing for services according to my country's regulations, but it shouldn't be too hard to make it universal (I'd love some help here, especially in form of examples of invoices for other countries). Did I spend more time on it that I would if I used a web tool for invoices? Yes. Do I expect to ultimately get ahead on this solution? Maybe. Is it worth it? The interface (read: an org-mode document invoking some elisp) is already more fluid than any web tool I've ever seen, and I don't need to be on-line - so a huge YES!

shoover 8y ago
Interesting use of orgmode as a database. How does it work? Does that use a built in agenda functionality or are you calling lower level org functions to query your agenda files and enumerating the results to generate the table as text in another buffer?
- TeMPOraL 8y ago
  I use proper org-mode functions to query the built-in agenda and then group entries by org-mode tags. My code expects a configuration that maps tags to their line item names (as on invoice), hourly rates and applicable tax. I use this to output a dynamic[0] table like this: | Tag | Invoice line name | Hours | Rate | Net | VAT % | VAT amount | Total | |-----------------+-----------------------+-------+-------+--------+-------+------------+--------| | meeting | Meetings | 10 | 12.00 | 120.00 | NP | 0.00 | 120.00 | | procrastinating | Important tasks | 20 | 13.00 | 260.00 | NP | 0.00 | 260.00 | | hn | Other important tasks | 40 | 14.00 | 560.00 | NP | 0.00 | 560.00 | | coding | Occasional code | 3 | 15.00 | 45.00 | NP | 0.00 | 45.00 | |-----------------+-----------------------+-------+-------+--------+-------+------------+--------| | Totals | - | 73 | - | 985.00 | - | 0.00 | 985.00 | #+TBLFM: @>$3=vsum(@2..@-1)::@>$5=vsum(@2..@-1);%.2f::@>$7=vsum(@2..@-1);%.2f::@>$8=vsum(@2..@-1);%.2f::$5=$3*$4;%.2f::$7=if(typeof($6) < 10, $5*$6, 0);%.2f::$8=$7+$5;%.2f The #+TBLFM: line at the bottom is org-mode spreadsheet functionality; it ensures I can modify the table text in-place, and just press C-c C-c to recalculate all values in it. I generate a similar table with data for invoices; some taken from my configuration, some computed (e.g. invoice number is generated by looking at filenames of previous invoices; sale date and service period are estimated from current date and the time range you specified when generating line items table, etc.). The code for generating above table is hand-crafted. While org-mode provides you a generator for agenda tables based on TODO item name - see [1], I had to write similar feature that aggregated time by org-mode tags. I used [2] as a reference, but essentially wrote my own implementation. Surprisingly, it turned out to be almost trivial. Then, it's simply a matter of turning those two org-mode tables into an elisp list of keys and values. This I accomplish using a simple elisp that uses built-in Emacs calls: (defun trc-invoicing--named-table-to-lisp (name) "Convert a named org mode table in the current buffer into a list. The function finds a table named `NAME', passes it through `ORG-TABLE-TO-LISP', and return the result. Refer to the documentation of `ORG-TABLE-TO-LISP' for info about result's shape." (save-excursion (goto-char (point-min)) (search-forward (format "#+NAME: %s" name)) (forward-line) (org-table-to-lisp))) Then it's a matter of populating a LaTeX template with extracted values, invoking pdflatex, and copying the resulting PDF in an appropriate place. That last part I yet have to finish. It's the biggest piece of elisp I wrote since Nyan Mode, but all in all, I find it surprisingly easy to code for Emacs. Availability of source code, extensive in-editor documentation and built-in source-level debugger make this process pretty pleasant. -- [0] - Org Mode has a concept of "dynamic blocks". You type in #+BEGIN: blockname some params, and then using C-c C-c on it causes Org Mode to invoke an elisp function named org-dblock-write:blockname. The called function is then responsible for outputting contents of the dynamic block. [1] - http://orgmode.org/manual/The-clock-table.html http://orgmode.org/manual/The-clock-table.html [2] - https://gist.github.com/tsu-nera/d9ffa6a51a6e7bdb957b https://gist.github.com/tsu-nera/d9ffa6a51a6e7bdb957b

shoover 8y ago

I often get stuck somewhere between a one-off keyboard macro and finding a pre-written full-blown mode but resist learning the techniques and functions needed to do this powerful in between workflow automation. Care to share a snippet?