emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sqlite3


From: Alexandre Garreau
Subject: Re: sqlite3
Date: Thu, 09 Dec 2021 17:21:16 +0100

Le ĵaŭdo, 9-a de decembro 2021, 11-a horo kaj 16:50 CET Eli Zaretskii a 
écrit :
> > From: Óscar Fuentes <ofv@wanadoo.es>
> > Date: Thu, 09 Dec 2021 10:50:56 +0100
> 
> > Eli Zaretskii <eliz@gnu.org> writes:
> 
> 
> 
> > > Unless that tool comes with the library in the same package, that
> > > is.
> 
> 
> 
> > You have to know about its existence and how to use it.
> 
> That information is just one  Internet search away.  Try:
> 
>    compare sqlite databases

To me that looks like a bad argument in favor of replacing plain text by 
sqlite, in opposition to the argument “everybody already knows plain text, 
how to read and edit it”.  A lot more convincing answer to me is “make 
that tool autoloaded for the right extension/magic number for sqlite3 
databases, and learn about it with C-h m, just as usual with any mode in 
emacs”, and “present the sqlite buffer as plaintext just as we already do 
for directories with dired, and allow to edit it with text commands just 
as editable dired”.

The “text files everybody knows how to read and edit them” is a real 
philosophy, coming from the unix background.  I can understand its 
limitations, but it shouldn’t be repelled by a mere classical unfriendly 
“google is your friend” (a search engine stays a so big and costly thing, 
that currently there is no decent free-software one, they all are 
proprietary and centralized, and the only correct one either depend on ads 
(google stays the main one, and is considered as a base standard of 
quality (which is hardly attained by many competitors) for many people 
requiring others to websearch stuff by themselves), or are based in the 
patriot-act US (duckduckgo))..



reply via email to

[Prev in Thread] Current Thread [Next in Thread]