From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jean Louis Newsgroups: gmane.emacs.help Subject: Stages of WWW development compared to Emacs Lisp development Date: Sun, 2 May 2021 15:06:27 +0300 Message-ID: References: <875z03th9b.fsf@web.de> <87v981wv3f.fsf@web.de> <20210502090647.GB9577@tuxteam.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27286"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.0.6 (2021-03-06) Cc: Michael Heerdegen , help-gnu-emacs@gnu.org To: tomas@tuxteam.de Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Sun May 02 14:09:39 2021 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ldAum-0006rW-1F for geh-help-gnu-emacs@m.gmane-mx.org; Sun, 02 May 2021 14:09:36 +0200 Original-Received: from localhost ([::1]:48078 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ldAul-0002BO-4w for geh-help-gnu-emacs@m.gmane-mx.org; Sun, 02 May 2021 08:09:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60518) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ldAu3-0001zm-I6 for help-gnu-emacs@gnu.org; Sun, 02 May 2021 08:08:51 -0400 Original-Received: from stw1.rcdrun.com ([217.170.207.13]:35171) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ldAu0-00064I-UT for help-gnu-emacs@gnu.org; Sun, 02 May 2021 08:08:51 -0400 Original-Received: from localhost ([::ffff:154.227.44.235]) (AUTH: PLAIN securesender, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 0000000000046166.00000000608E964D.00006769; Sun, 02 May 2021 05:08:45 -0700 Mail-Followup-To: tomas@tuxteam.de, Michael Heerdegen , help-gnu-emacs@gnu.org Content-Disposition: inline In-Reply-To: <20210502090647.GB9577@tuxteam.de> Received-SPF: pass client-ip=217.170.207.13; envelope-from=bugs@gnu.support; helo=stw1.rcdrun.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:129325 Archived-At: As in the context of templating engines, WWW development is very similar to Emacs Lisp development or any programming language. One has to try it out, there are maybe some trials and errors, there is debugging involved, preview or testing, editing, preview or testing, until it becomes what author wants it to be. One bad example that I can think of in using `read-from-string' and `eval' in templates is when strings from visitor's input would be processed with it. For example, if visitor would be asked for email, and that email address is then, instead of obtained from environment like POST, processed by `read-from-string' -- at this moment I would not know why it should be so, unless website wants to evaluate some programming code. There are today so many websites evaluating programming code in browser. Who knows how secure they are... By principle, I do not keep the database online, at least privacy is ensured. Attacker on a website could eventually send spam or use some band width, but nothing more than that. The comparison of web templating engines shows that many of them are using "functions": https://en.wikipedia.org/wiki/Comparison_of_web_template_engines I see that Perl's Template Toolkit probably uses `eval': https://github.com/abw/Template2/search?q=eval&type= In this list for Python templating engines, two of them are mentioned using `eval' I rather think there are more than two: https://wiki.python.org/moin/Templating Or this Tiny Template, that says not to use `eval' but it is restricted in operation: https://github.com/yuanchuan/tiny-template And my intention is not to be restricted in operation. I was doing for years preparation of variables, etc. so that I can pass it to the templating engine like CL-EMB, but I think that was more because of Common Lisp nature of packages, I would need to call functions with their prefixes. Global variables were anyway present, and I could anyway evaluate any Common Lisp code in CL-EMB. >From CL-EMB: - `<% ... %>` is a scriptlet tag, and wraps Common Lisp code. - `<%= ... %>` is an expression tag. Its content gets evaluated and fed as a parameter to `(FORMAT T "~A" ...)`. - `<%# ... #%>` is a comment. Everything within will be removed/ignored. Can't be nested! I have just minimized it to the system that can use various delimiters, including just parenthesis (would the remaining text not use parenthesis with spaces): ( anything ) would be evaluated while (anything) would not. And I can skip the CL-EMB's tag <%= something %> into ( something ) or ⟦ something ⟧ and I skip using complex tags like <% @var VARIABLE %> as ⟦ VARIABLE ⟧ will work or expand empty. In CL-EMB there are some template tags, while any Lisp can be embedded anyway: Currently supported: `@if`, `@else`, `@endif`, `@ifnotempty`, `@unless`, `@endunless`, `@var`, `@repeat`, `@endrepeat`, `@loop`, `@endloop`, `@include`, `@includevar`, `@call`, `@with`, `@endwith`, `@set`, `@genloop`, `@endgenloop`, `@insert`. It is more complex templating engine, one can have separate chunks of embedded templating tags which then work together with the mixed text inside, great, but also complex. It mixes 2 languages, one is templating language and one is Lisp. Instead, why not just use Lisp. Process of preparing pages for evaluation is simple: - edit page - preview - edit and preview until satisfied - publish In that sense whatever can go wrong with sex-pression templates or Scribe style of preparation, it can also go wrong with `eval' based templating engine. Muse can embed any kind of Emacs Lisp and anyway does not have good visualization of it. Org mode embeds any kind of programming. I am using Org mode and expanding it from outside of Emacs by using Common Lisp which invokes Emacs each time, and I guess that makes things slower. If I manage the Website Revision System directly from Emacs, it will be somewhat faster to expand Org blobs from database. Following Common Lisp is used to convert stream of Org data to Markdown markup: $ cat file.org | pipe-org-to-markdown.lisp #!/home/data1/protected/bin/lisp (defparameter memdir "/dev/shm/") (defparameter tmp-file "rcd-wrs-XXXXXX") (defparameter tmp-org (format nil "~a~a.org" memdir tmp-file)) (defparameter tmp-md (format nil "~a~a.md" memdir tmp-file)) ;;(delete-file tmp-org) ;;(delete-file tmp-md) (load "/home/data1/protected/Programming/git/RCDBusiness/lib/lisp/streamtools.lisp") ;; (require "syscalls") (defparameter org-autoloads.el (concatenate 'string (namestring (car (directory "/home/data1/protected/.emacs.d/elpa/org-20??????/"))) "org-autoloads.el")) (defun main () (let ((input '()) (output '())) (with-open-file (out tmp-org :direction :output :external-format "utf-8" :if-exists :supersede) (loop for line = (read-line *standard-input* nil nil) while line do (write-line line out))) (shell (format nil "emacs -Q -l ~a \"~a\" --batch -f org-mode -f org-md-export-to-markdown --kill" org-autoloads.el tmp-org)) (setf output (with-open-file (stream tmp-md :direction :input :external-format "utf-8") (loop for line = (read-line stream nil nil) while line collect line))) (setf output (format nil "~{~a~^~%~}" output)) (setf output (slurp-stream-io-command "markdown -F 0x4" output)) (princ output)) (exit)) ;; ;; (saveinitmem "org2html" :quiet t :init-function 'main :verbose nil :norc t :documentation "Converts Org standard input into markdown" :executable t) (main) -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns Sign an open letter in support of Richard M. Stallman https://stallmansupport.org/ https://rms-support-letter.github.io/