trying to fix

var/elfeed/db/data/f8/f8c46f96ff06415c9bb0f284b994e2c883530ab2

@@ -0,0 +1,179 @@
+
+         
+         <p>Raw link: <a href="https://www.youtube.com/watch?v=RiXK7NALgRs">https://www.youtube.com/watch?v=RiXK7NALgRs</a></p>
+         
+         <p>In this video blog I talk about the persistent question of “the killer
+app” that gets asked in the Emacs community.  I explain why I think the
+identification of a single package is often not enough to appreciate the
+true value proposition of Emacs.  My case emphasises the importance of
+workflows; workflows that typically combine lots of distinct tools and
+benefit from core Emacs attributes.  It is the whole system that
+matters, because all those packages—in their given combinations—make
+up our day-to-day computing experience with Emacs.</p>
+
+<p>The text of the presentation is written in <code>org-mode</code> notation and is
+reproduced below.  Also check my Emacs configuration file, from where
+you can get the code I use: <a href="https://protesilaos.com/emacs/dotemacs">https://protesilaos.com/emacs/dotemacs</a>.</p>
+
+<hr />
+
+<pre><code class="language-org">#+TITLE: Vlog: Emacs is my “favourite Emacs package”
+#+AUTHOR: Protesilaos Stavrou · protesilaos.com
+
+* Getting into the Emacs mindset
+
+I will to talk to you about my approach to a recurring topic in the
+Emacs community, best encapsulated in this question:
+
+/What is your favourite package?/
+
+Similar formulations:
+
++ What is the one thing that makes Emacs indispensable to you?
++ Which is Emacs' killer app?
+
+Such questions can lead us to valuable findings.  There is truth to be
+had in the insights drawn from them and we must learn as much as we can
+in the process.
+
+Note though that this type of inquiry expects from us to engage in an
+analytical exercise that extracts an object from its milieu.  It puts us
+in a frame of mind that can miss the true value proposition of Emacs.
+
+The problématique comes with the latent risk of holding us captive to a
+frame of mind characterised by *decontextualisation*, of examining an
+object without reference to the environment that renders it possible.
+
+Instead of thinking about workflows that can take you from one context
+to another, we are expected to identify some silo of functionalities.
+Are we then underestimating everything else that contributes to our
+day-to-day /experience/ with Emacs?
+
+* Don't ignore the forest while looking at the tree
+
+Now before I get misunderstood: yes, Org and Magit are great; yes, there
+are lots of individual packages that make your life easier; and yes,
+there is value in finding which package[s] people enjoy the most.
+
+What about the combination of all utilities?  What about the *gestalt*?
+
+If you claim that “my favourite package is X” and then fail to couch
+your statement in terms of the rest of the toolkit you rely on, you are
+likely to underappreciate---or altogether ignore---the true value
+proposition of Emacs.
+
+You do not acknowledge how the whole system is pieced together.  More
+importantly, you may not realise the potential of Emacs' extensibility,
+which is dynamic or case-dependent.
+
+In other words, Emacs provides the means to implement a metaphor like
+that of the vaunted Unix pipes across its entire space.  In practical
+terms, you can connect your email client to your agenda, your RSS reader
+to your custom note-taking system, your music manager to your directory
+editor, and so on.  And all these can benefit from interfaces for
+searching, editing in bulk, etc.
+
+My claim here is that most of the times there is no one package or
+narrow subset that make Emacs great.  It rather is the linkages between
+several pieces of code that make Emacs a pleasure to work with.  They
+contribute to predictable-yet-flexible workflows.  These keep Emacs
+relevant and, dare I say, intriguing.
+
+* The three core attributes of Emacs
+
+Emacs is programmable and introspectable.  Both presuppose transparency.
+These make the Emacs experience open-ended.
+
++ Programmable :: One set of features can be made to interface with
+  another, even though it was not conceived with the express purpose of
+  optimising for that particular scenario.  What can be done with Emacs
+  is not predetermined.  There is always scope for something new.
+
++ Introspectable :: The user can examine the entire code base or a
+  specific implementation and, potentially, figure out how to connect to
+  it through some other tool.  This is further supported by the robust
+  self-documentation facilities of Emacs, as well as the high quality of
+  material that is readily available through the built-in Info reader.
+  Introspection has contributed to the /documentation culture/ that
+  characterises the Emacs community at-large.
+
++ Transparent :: Emacs does not conceal its internals.  Virtually every
+  case can be handled using the same language the code is written in
+  (Emacs Lisp) while benefiting from live evaluation of new code.  You
+  change something and you see it in action.  Combined with the
+  self-documenting nature of Emacs, transparency provides insight into
+  practically every single construct that makes up Elisp.  Which
+  empowers us to make best use of Emacs' programmability.
+
+When considered together, these engender the *interconnectedness* that
+defines the Emacs space.
+* Introspection in action
+
+Quick demo of running =C-h o= (=describe-symbol=) over =mapcar= and =mapconcat=
+and then testing those expressions.
+
+#+begin_src emacs-lisp
+(mapcar #'upcase '("one" "two" "three"))
+
+(mapconcat #'upcase '("one" "two" "three") "-")
+#+end_src
+
+We can use =C-x C-e= (=eval-last-sexp=) to get live feedback of what each
+function does.
+
+We can check the log with =C-h e= (=view-echo-area-messages=).
+
+These are the rudimentary tools you rely on to start using ELisp.  They
+offer you the means to experiment with how to extend Emacs.
+* A quick look at combining tools
+
+Now let me switch to another window layout, where I have some plain text
+files in a standard directory.  Nothing fancy here.  Just to show how
+standard Emacs tools can combine together to deliver a consistent
+computing experience.
+
++ Switching to another layout involves the built-in tabs (=tab-bar-mode=)
+  plus some bespoke code of mine.
++ Find file at point using a filename or just part of a file (=C-x C-f M-n=).
++ Use a completion framework (=icomplete-mode= in my case).
++ Benefit from a pattern-matching style (=orderless= for me).
++ Jump to the directory that contains the file (=dired-jump=).
++ While in Dired, jump to an item using completion (=dired-goto-file=).
++ Or filter the Dired list and then find the item (=% m= potentially
+  followed by =t k=).
+
+* Interconnectedness in the Emacs space
+
+My point is to highlight the true value of Emacs' extensibility.  Which
+is realised in the connections you make between several pieces of
+functionality.
+
+And, as I already mentioned, one package does not need to know about the
+presence of another /in advance/.
+
+Your focus should be on the workflow.  On the whole system that helps
+you get things done with Emacs.  Because that is what your actual
+experience is about.  You benefit from the set of /emergent qualities/
+that become available in the combination of otherwise disparate pieces
+of functionality.
+
+Let me stress the importance of interconnectedness in the Emacs space by
+showing you another quick demo that combines three distinct packages
+that were not developed for the express purpose of being combined
+together:
+
++ =elfeed= for reading RSS/Atom feeds.
++ =bongo= for managing media files or links.
++ And my own experimental note-taking system (=usls=).
+
+Finally, this entire presentation is made possible by combining several
+tools:
+
++ =org-mode=
++ =olivetti-mode=
++ =org-tree-slide-mode=
++ =variable-pitch-mode=
++ my own commands for setting fonts
+</code></pre>
+        
+